On Firefox st.audio plays the input from st.audio_input sped up and twice
RonaldAJ opened this issue · comments
Checklist
- I have searched the existing issues for similar issues.
- I added a very descriptive title to this issue.
- I have provided sufficient information below to help reproduce this issue.
Summary
When I make a recording with st.audio_input and use st.audio to play it the input from st.audio_input is played at high speed and then repeated.
Reproducible Code Example
In the documentation example for st.audio:
import streamlit as st
audio_value = st.audio_input("Record a voice message")
if audio_value:
st.audio(audio_value)Steps To Reproduce
To reproduce on Firefox:
- attach a mono USB microphone (I have a GoMic from Samson)
- goto: https://docs.streamlit.io/develop/api-reference/widgets/st.audio_input
- record and make a single sound like clicking your tongue
- stop the recording
- play the recording from st.audio (playing from the input device works correctly)
On Edge it works correctly.
Expected Behavior
I expect to hear the sound made during the recording played at normal speed and only once.
Current Behavior
Despite clicking my tongue a single time I hear two clicks and the recording sounds like it is sped up.
Is this a regression?
- Yes, this used to work in a previous version.
Debug info
- https://docs.streamlit.io/develop/api-reference/widgets/st.audio_input accessed at 6 november 2024
- Browser: Firefox
Additional Information
Note:
My firefox version is: Versie 132.0.1 (64-bits) on Windows10.
If this issue affects you, please react with a 👍 (thumbs up emoji) to the initial post.
Your feedback helps us prioritize which bugs to investigate and address first.
Hey @RonaldAJ , I wasn't able to reproduce this issue locally on my MacBook microphone:(
Do you have any ideas, though on what could be a cause of this behaviour (maybe microphone specific software, or any other preprocessing)?
As the set-up is the same between Edge and Firefox, with Edge working correctly and Firefox not working correctly it could well be that the root cause is not in streamlit. As I am unfamiliar with typescript I cannot analyze much further.
The fast speed suggests the data provided is read as if an input with two channels was expected while in fact a single channel was provided. What is at odds with that idea is the repetition of the sounds.
A possible scenario is that the samples are read as 32 bit while being stored as 16 bit and then the two channels are merged into 1 leading to a repetition. Audio as perceived is remarkably robust against these type of signal deformations.
I wasn't able to reproduce this issue. I tested on Chrome, Safari, Edge, and Firefox, and they all worked correctly. FYI: @kajarenc
@kasim-inan Just to make sure: you did play with st.audio as opposed to the widget used for the recording?
Firefox in my ubuntu 20 VM under virtualbox behaves the same as under windows. Brave works correctly.
Hey @RonaldAJ ! I was able to confirm it. Looks like something in how Firefox is setting up the audio and how we upload it. I made a PR that should address it. I'd like to do some rigorous testing and make sure things work well for all use cases. Would appreciate if you confirmed the issue is resolved on your setup (Would love if other browsers were tested and verified as well.
The wheel file is https://core-previews.s3-us-west-2.amazonaws.com/pr-9885/streamlit-1.40.1-py2.py3-none-any.whl
Once downloaded you should uninstall streamlit and install streamlit with pip install streamlit-1.40.1-py2.py3-none-any.whl.
Appreciate help in getting this bug fixed :-)
I reproduced the bug locally using firefox with the 1.40.0 release in a dedicated virtual environment:
Steps:
- Create a virtual environment:
python3 -m venv sa3_10_st_notfixed - Activate the environment:
activate sa3_10_st_notfixed/bin/activate - Install streamlit:
pip install streamlit==1.40 - Save the following code to
streamlit_audio_test.py:
import streamlit as st
f'{st.__version__=}'
audio_value = st.audio_input("Record a voice message")
if audio_value:
st.audio(audio_value)- run the streamlit script: `streamlit run streamlit_audio_test.py
- Perform the original reproduction steps.
Outcome:
Recorded one click, st.audio produced two on playback.
Then I failed to reproduce the bug locally using firefox with the provided wheel in a second dedicated virtual environment:
Steps: Essentially the same but with the streamlit install step replaced by:
pip install streamlit-1.40.1-py2.py3-none-any.whl using the wheel provided by @kmcgrady.
Outcome:
Recorded one click, st.audio produced one on playback.
So it looks like the bug is fixed for Firefox (Version 132.0.2). Also checked Brave and it works with both versions.
Extra data on environment: Python 3.10.12, Ubuntu 22.04.5 LTS
@kmcgrady I had a look at the code, but I lack the context knowledge to judge it.
Awesome! Thank you @RonaldAJ for testing and verifying. I'll get this reviewed internally and should get this into the next release.