Hi Borge, J Kenny UnixMan et al,
This is a known issue for some time. It happens when you change tracks in the middle of a song when playing with some music playback programs, or as UnixMan reported pausing the audio stream suddenly in the middle of a song.
I may have finally found a way to fix it. Please test the latest firmware and see whether it works. It seems to work for me under uac2. I have not tested under uac1 yet.
audio-widget-nik-2011-12-28.elf - sdr-widget - Unified firmware for audio-widget. Fixed 100ms funny noise when changing tracks or pause/resume in middle of song. - Audio and Control Interface for Amateur Radio SDR and Audiophile USB-DAC - Google Proj
Alex
PS. UnixMan, if you can hear the SQ difference with the new firmware, please feedback whether it is better or worse. The difference in the latest firmware is that it uses 32 bit transfers all the way to the DAC. However, our current DAC is only 24 bit capable and may have difficulty with "bumper-to-bumper" I2S that Borge is concerned about.
This is a known issue for some time. It happens when you change tracks in the middle of a song when playing with some music playback programs, or as UnixMan reported pausing the audio stream suddenly in the middle of a song.
I may have finally found a way to fix it. Please test the latest firmware and see whether it works. It seems to work for me under uac2. I have not tested under uac1 yet.
audio-widget-nik-2011-12-28.elf - sdr-widget - Unified firmware for audio-widget. Fixed 100ms funny noise when changing tracks or pause/resume in middle of song. - Audio and Control Interface for Amateur Radio SDR and Audiophile USB-DAC - Google Proj
Alex
PS. UnixMan, if you can hear the SQ difference with the new firmware, please feedback whether it is better or worse. The difference in the latest firmware is that it uses 32 bit transfers all the way to the DAC. However, our current DAC is only 24 bit capable and may have difficulty with "bumper-to-bumper" I2S that Borge is concerned about.
Hi Alex,
Thanks for your efforts!
I'm testing on Win7-64. UAC1 is silent. I took the liberty of adding that to the description. UAC2 works like a charm. The previous issues I had (Video Lan Client player, song skip gives chirp) are not there.
But then again, on UAC2 / audio-widget-nik-20111226 the issues are not there either. I don't know if these are the same issues as UnixMan is having.
However, UAC1 / audio-widget-nik-20111226 have the chirps.
The SQ issues are probably due to me shipping some kits with too old firmware. Therefore, please use the programming kit in Add_to_flip345_bin.zip or install audio-widget-nik-20111126 manually.
Børge
Thanks for your efforts!
I'm testing on Win7-64. UAC1 is silent. I took the liberty of adding that to the description. UAC2 works like a charm. The previous issues I had (Video Lan Client player, song skip gives chirp) are not there.
But then again, on UAC2 / audio-widget-nik-20111226 the issues are not there either. I don't know if these are the same issues as UnixMan is having.
However, UAC1 / audio-widget-nik-20111226 have the chirps.
The SQ issues are probably due to me shipping some kits with too old firmware. Therefore, please use the programming kit in Add_to_flip345_bin.zip or install audio-widget-nik-20111126 manually.
Børge
nope.
Downloaded and flashed:
Code:
./program-widget.sh audio-widget-nik-2011-12-28.elf
program-widget with audio-widget-nik-2011-12-28.elf
target: at32uc3a3256
chip_id: 0x2ff1
vendor_id: 0x03eb
command: erase
quiet: false
debug: 6
device_type: AVR32
------ command specific below ------
validate: true
target: at32uc3a3256
chip_id: 0x2ff1
vendor_id: 0x03eb
command: flash
quiet: false
debug: 6
device_type: AVR32
------ command specific below ------
validate: true
hex file: /tmp/audio-widget-nik-2011-12-28.hex
Validating...
115496 bytes used (45.48%)
target: at32uc3a3256
chip_id: 0x2ff1
vendor_id: 0x03eb
command: reset
quiet: false
debug: 4
device_type: AVR32
------ command specific below ------Although perhaps the noise produced during "pause" changed a little bit. It sounds like the widget is looping re-playing the last received sample(s): rat-ta-ta-ta-ta-ta... as before, but now the repetition "frequency" (rate) seems to have reduced a bit (and so seems to have done also the "pitch" of the produced noise).
slightly better. But, as Børge said, I had some very old version before, so there's much more than just the 24/32bit thing.
Still, I wonder why/how the firmware could change the SQ...
Hi all,
OK. Maybe a little explanation on why there is the chirp and why it is so difficult to fix.
Unlike many (most) other soundcards, the audio-widgets has async with rate feedback. There is an internal circular buffer that continues to output to the I2S, and the incoming USB data is used to fill the buffer. The incoming USB rate is throttled with rate feedback to get the circular buffer going without buffer over or under flow.
When the incoming USB data stream is stopped suddenly (without the music playback program and/or the driver sending commands such as USB set alternate setting to zero (which is the zero bandwidgth USB alternate setting), the circular buffer continues to circulate, AND the firmware tries to do rate feedback correction furiously. Thus there is this 100ms chirp before finally the USB alternate setting is set to zero by the music player software and/or the audio driver.
So this explains:
1. Why "other" soundcards do not have this issue. 'Cos they are probably not async with rate feedback.
2. Why there is this issue with some music playback software only. Under Windows, PurePlayer does not have this issue. I suspect it is because it (correctly) mutes the playback stream before stopping the audio (via the driver) before skipping tracks. Other software may not mute the playback stream, but sends the USB set alternate setting to zero ASAP, thus mutes the chirp within a short time (shorter than 100ms).
3. UnixMan's pausing of the playback with the command line probably is one of those situations where the audio stream is stopped abruptly without the audio driver being informed, and thus the alsa driver will not set the alternate setting to zero immediately (this will eventually happen when the alsa driver times out without incoming audio data.) In the meantime the audio-widget is chirping
So for the muting to work, there must be some signal from the host that the audio stream is stopping. Just merely stopping the stream abruptly is not good enough. The audio-widget will think that it is just a temporary situation and more data will be coming through shortly. In the meantime the audio-widget will frantically signal via the feedback rate that the host should send faster
My own solution is not to skip tracks, but to listen to the whole song from start to finish
Alex
OK. Maybe a little explanation on why there is the chirp and why it is so difficult to fix.
Unlike many (most) other soundcards, the audio-widgets has async with rate feedback. There is an internal circular buffer that continues to output to the I2S, and the incoming USB data is used to fill the buffer. The incoming USB rate is throttled with rate feedback to get the circular buffer going without buffer over or under flow.
When the incoming USB data stream is stopped suddenly (without the music playback program and/or the driver sending commands such as USB set alternate setting to zero (which is the zero bandwidgth USB alternate setting), the circular buffer continues to circulate, AND the firmware tries to do rate feedback correction furiously. Thus there is this 100ms chirp before finally the USB alternate setting is set to zero by the music player software and/or the audio driver.
So this explains:
1. Why "other" soundcards do not have this issue. 'Cos they are probably not async with rate feedback.
2. Why there is this issue with some music playback software only. Under Windows, PurePlayer does not have this issue. I suspect it is because it (correctly) mutes the playback stream before stopping the audio (via the driver) before skipping tracks. Other software may not mute the playback stream, but sends the USB set alternate setting to zero ASAP, thus mutes the chirp within a short time (shorter than 100ms).
3. UnixMan's pausing of the playback with the command line probably is one of those situations where the audio stream is stopped abruptly without the audio driver being informed, and thus the alsa driver will not set the alternate setting to zero immediately (this will eventually happen when the alsa driver times out without incoming audio data.) In the meantime the audio-widget is chirping
So for the muting to work, there must be some signal from the host that the audio stream is stopping. Just merely stopping the stream abruptly is not good enough. The audio-widget will think that it is just a temporary situation and more data will be coming through shortly. In the meantime the audio-widget will frantically signal via the feedback rate that the host should send faster
My own solution is not to skip tracks, but to listen to the whole song from start to finish
Alex
My own solution is not to skip tracks, but to listen to the whole song from start to finish
Good thinking Alex! Unfortunately, some players give chirps when they go from one song to the next without user intervention.
It's good that you point out the causes. Could you please refer to where in the code these things are going on?
I'm sure you have considered the alternatives and whether it would make sense for the feedback routine to simply give up at some point.
Which of your changes are in the git repository?
Børge
Last edited:
Hi Borge et al,
Fixed. uac1 and uac2 both have the 100ms chirpy noise fix put in and uac1 plays music now
The skipping track mute works best when you play a track for a short while before skipping. If you skip and skip and skip within < 1 sec the rate feedback has not stablized to a good lock yet and fast skipping will break the lock. So listen for 5 seconds before skipping to the next song.
uac2 is working very well. uac1 works but on my Linux PC the rate feedback sync lock is not very secure (indicated by the red and green LED flashing alternatively every 1 sec or so). I will tweak the rate feedback of uac1 when I am free. (We have been tweaking the uac2 rate feedback extensively so it is working very well. Didn
Fixed. uac1 and uac2 both have the 100ms chirpy noise fix put in and uac1 plays music now
The skipping track mute works best when you play a track for a short while before skipping. If you skip and skip and skip within < 1 sec the rate feedback has not stablized to a good lock yet and fast skipping will break the lock. So listen for 5 seconds before skipping to the next song.
uac2 is working very well. uac1 works but on my Linux PC the rate feedback sync lock is not very secure (indicated by the red and green LED flashing alternatively every 1 sec or so). I will tweak the rate feedback of uac1 when I am free. (We have been tweaking the uac2 rate feedback extensively so it is working very well. Didn
No, that's not exactly what happen in the case I described. In that case it's not just a brief "chirp", the noise keeps goin' on forever, until the "play" process is resumed!
I guess this happen with any player (verified with various different players, including GUI-based ones such as "gogglesmm") if you stop the player process (sending sigstop signal) while it's playing.
Isn't it possible for the widget firmware to detect that the USB stream have been interrupted and consequently stop also the I2S stream (or fill it with zeroes) until a resume of the incoming USB stream is detected?
I guess that if it has no new data from the host, it should fill the circular buffer with zeroes (or stop looping altogether) rather than keep looping the last stored samples.
Also in case of accidental underruns, a brief "hole" (silence) is probably better than a noisy "chirp".
granted...
this seems to never happen...and thus the alsa driver will not set the alternate setting to zero immediately (this will eventually happen when the alsa driver times out without incoming audio data.) In the meantime the audio-widget is chirping
well, I guess the logic should be changed somehow... see above.
that's a workaround, not a fix...My own solution is not to skip tracks, but to listen to the whole song from start to finish
Last edited:
post got truncated.
(I guess you too sent it right before diyAudio server night mainteinance... in principle the post sending is resumed automatically as soon as the server goes back up, but it looks like there's a bug and all post sent that way got truncated).
Fixed. uac1 and uac2 both have the 100ms chirpy noise fix put in and uac1 plays music now
Hi Alex, we should get you a Win7 system... I'm experiencing weird things with UAC1 from your newest fw... (UAC2 is working perfectly, though!)
When I play a CD in Video Lan Client there are still chirps when I skip, regardless of where in the song I do that.
When I stream music with the Wimp program and skip, chirps are there. At some point, a skip caused the player to stop/pause. But it doesn't always do that. I'll check again after a reboot.
But the weirdest thing is that the Win7 test tones play Left-Left or Right-Right, not the expected Left-Right. Now, this test isn't always perfect, but this is the first time I see this kind of channel confusion. On earlier occations this test has given me some chiprs too.
May it be that USB communication is halted at a random point, and not at the end of an L:R sample pair? (Not that I know the proper terms for this, as you see from my way of asking.)
Børge
