Have a look at the github part of the SDR Widget wiki. The text is a little messy, but all should be there.
Go back to '26 to be on the safe side...
Børge
Go back to '26 to be on the safe side...
Børge
This is the latest firmware:
audio-widget-nik-2011-12-28e.elf - sdr-widget - Unified firmware for audio-widget. Fixed 100ms funny noise when changing tracks or pause/resume in middle of song for uac2 only. uac1 fix not applied because of channel inversion issue. - Audio and Cont
For the source code, go to github and search for sdr-widget.
Alex
audio-widget-nik-2011-12-28e.elf - sdr-widget - Unified firmware for audio-widget. Fixed 100ms funny noise when changing tracks or pause/resume in middle of song for uac2 only. uac1 fix not applied because of channel inversion issue. - Audio and Cont
For the source code, go to github and search for sdr-widget.
Alex
Thanks Alex,
Could you please point to your more or less successfull edits so that the new guys on the list can give it a go? Navigating a large code base can be somewhat intimidating...
Børge
Could you please point to your more or less successfull edits so that the new guys on the list can give it a go? Navigating a large code base can be somewhat intimidating...
Børge
It will be intimidating. There are no short cuts. You will need to read the 144 page UAC2 specs and the Atmel UC3A3 reference and many other documents.
To get a feel of the latest updates you need to know git or use the github browser interface to look at recent commits. Personally I use gitk to quickly navigate the commits.
New comer developers are welcome to make local branches to play with the code. When you are confident of your codes we can add you to the developer's list so that you can push updates to the code base.
Don't complain that the code is difficult to understand. It is sparsely documented and the comments are terse. It uses a real time operating system and is highly multithreaded. It is a team development and different parts are written by different people and it has evolved over time. Some of the code has been written in a particular way which is not elegant, but for performance reasons as we are nearing the processing power limit of the CPU.
I will try to answer questions as best as I can given my limited free time but don't expect any hand holding 🙂
Alex
To get a feel of the latest updates you need to know git or use the github browser interface to look at recent commits. Personally I use gitk to quickly navigate the commits.
New comer developers are welcome to make local branches to play with the code. When you are confident of your codes we can add you to the developer's list so that you can push updates to the code base.
Don't complain that the code is difficult to understand. It is sparsely documented and the comments are terse. It uses a real time operating system and is highly multithreaded. It is a team development and different parts are written by different people and it has evolved over time. Some of the code has been written in a particular way which is not elegant, but for performance reasons as we are nearing the processing power limit of the CPU.
I will try to answer questions as best as I can given my limited free time but don't expect any hand holding 🙂
Alex
Just tried audio-widget-nik-2011-12-28e. No changes, problem persist exactly as before.
BTW, I wonder: how is handled the buffer? do yo have two separate loops, one filling the buffer from the USB stream and the other "consuming" data from it and outputting to I2S?
Wouldn't it be possible to locally check for buffer underruns?
Without knowledge about all the details, I'd guess that what should be done is checking for buffer "fill level". If the buffer ever gets "empty", the loop reading data from the buffer to I2S should be stopped (and perhaps the rate feedback system should be "freezed" and put on hold too). It should not be restarted until the buffer gets half-full again.
I was afraid about that... 🙁It will be intimidating. There are no short cuts. You will need to read the 144 page UAC2 specs and the Atmel UC3A3 reference and many other documents.
BTW, I wonder: how is handled the buffer? do yo have two separate loops, one filling the buffer from the USB stream and the other "consuming" data from it and outputting to I2S?
Wouldn't it be possible to locally check for buffer underruns?
Without knowledge about all the details, I'd guess that what should be done is checking for buffer "fill level". If the buffer ever gets "empty", the loop reading data from the buffer to I2S should be stopped (and perhaps the rate feedback system should be "freezed" and put on hold too). It should not be restarted until the buffer gets half-full again.
I made a bunch of measurements of the AB1.1 when it was first shipped. I'll redo them once the code has settled. The performance was essentially at the spec for the ESS chip. There was some noise getting to the oscillators that was visible in the Jtest plots. I want to get the latest stable code before I redo them and I want Borge to be OK with publishing them. I did post the changes I made to the board based on the measurements.Hello all,
Does anyone has made some serious measurements on the Audio widget USB interface ?
(FFT spectral analysis,bode plot and more...)
Frex
I'm not sure how you would made a Bode plot since the delay from the PC processing may not be fixed. However I can measure the phase as well as the frequency against an arbitrary reference.
Hi,
Thank you 1audio, i'm interested by the Audio Widget and i will probably buy one when i finish my current projects.
Yes, Bode plot could be difficult, but you can only easily get a frequency response graph with a sweep frequency using digital file.
Regards.
Frex
Thank you 1audio, i'm interested by the Audio Widget and i will probably buy one when i finish my current projects.
Yes, Bode plot could be difficult, but you can only easily get a frequency response graph with a sweep frequency using digital file.
Regards.
Frex
My home theater surround decoder does this whenever the digital input experiences a gap. For example, my HDTV tuner has a digital audio output that feed the surround decoder, and every time I change channels I get a modulated chirp.So this explains:
1. Why "other" soundcards do not have this issue. 'Cos they are probably not async with rate feedback.
I realize this isn't a sound card at all, but the whole clock versus digital audio bit stream is common among everything described.
Basically, the challenge is that the player must keep up a constant stream of audio samples, ramping to zero and continuing to stream silence when the source material is unavailable. That seems to be the only way for the output to continue without sudden frequency modulation due to sample rate variations.
Hi rsdio et al,
Thanks for the useful info 🙂
I have uploaded the latest fix for the chirpy issue (before reading your post), basically using the same idea:
There is a "heart-beat" counter that beats when there is incoming USB data bound for the DAC. A watch-dog process checks that the heart-beat is ongoing. If it stops within a set time period (right now set to 5ms) the firmware assumes that the USB stream has suddenly stopped (without receiving a proper USB set alternate to zero command from the host driver to indicate proper USB streaming stop condition). So it zeros the audio buffer for the DAC to output silence.
Alex
Thanks for the useful info 🙂
I have uploaded the latest fix for the chirpy issue (before reading your post), basically using the same idea:
There is a "heart-beat" counter that beats when there is incoming USB data bound for the DAC. A watch-dog process checks that the heart-beat is ongoing. If it stops within a set time period (right now set to 5ms) the firmware assumes that the USB stream has suddenly stopped (without receiving a proper USB set alternate to zero command from the host driver to indicate proper USB streaming stop condition). So it zeros the audio buffer for the DAC to output silence.
Alex
makes sense. It seems more complex than it should be (really isn't it possible to simply check for buffer "fill level"? 🙁 ), but I guess you know what you're doing... 🙂I have uploaded the latest fix for the chirpy issue (before reading your post), basically using the same idea:
There is a "heart-beat" counter that beats when there is incoming USB data bound for the DAC. A watch-dog process [...]
Which version is this?
audio-widget-nik-2011-12-29.elf - sdr-widget - Unified firmware for audio-wdgets. Mostly fixed pause/skip chirp issue. - Audio and Control Interface for Amateur Radio SDR and Audiophile USB-DAC - Google Project Hosting
The buffer "fill level" cannot be checked reliably at a particular time (but over a period of time the "rough" level can be calculated). This is because the process that reads out the buffer is a hardware DMA running independently of the cpu.
Alex
The buffer "fill level" cannot be checked reliably at a particular time (but over a period of time the "rough" level can be calculated). This is because the process that reads out the buffer is a hardware DMA running independently of the cpu.
Alex
YEEESSSSSSSSSSS!!!!!!!!!

you did it!


Thanks a lot!

Oh, I see.This is because the process that reads out the buffer is a hardware DMA running independently of the cpu.
Last edited:
hi,
exactly which Kernel settings do I need for UAC2-Compliance with the audio-widget? Currently I use kernel 2.6.39-r3 for gentoo.
Rüdiger
exactly which Kernel settings do I need for UAC2-Compliance with the audio-widget? Currently I use kernel 2.6.39-r3 for gentoo.
Rüdiger
Any kernel >= 2.6.38 should do, no special settings required (of course you need to have ALSA with at least the usb drivers compiled, but that's normal for all "general purpose" kernels).
Any kernel >= 2.6.38 should do, no special settings required (of course you need to have ALSA with at least the usb drivers compiled, but that's normal for all "general purpose" kernels).
Yes, and that's my Q. I have a custom kernel where anything is disabled but my current requirements. So, I have ALSA and my current soundcard enabled. But nothing else. Regarding USB, I have EHCI and UHCI enabled, but nothing else. What does the widget need? 'The USB-Drivers' is a bit vague, as there are maybe one hundred different ones in menuconfig.
And i don't find an option that reads ''USB Class 2 Audio", but that would be to obvious for the linux kernel guys... 😉
Rüdiger
I guess all that you need is:'The USB-Drivers' is a bit vague, as there are maybe one hundred different ones in menuconfig.
And i don't find an option that reads ''USB Class 2 Audio"
Code:
CONFIG_SND_USB=y
CONFIG_SND_USB_AUDIO=m
BTW: I'd use the "Voyage MPD" kernel as a base. 😉
Last edited:
hm-hm. There isas well.Code:CONFIG_USB_AUDIO
Code:
$ grep -i CONFIG_USB_AUDIO /boot/config*
/boot/config-3.0.0-voyage:# CONFIG_USB_AUDIO is not set
/boot/config-3.1.0-1-686-pae:# CONFIG_USB_AUDIO is not set
perhpas that's for non-ALSA drivers (OSS?).
I have a question concerning the WidgetControl GUI tool.
On my window vista laptop, the python stuff doesn't install properly (wxpython complains not finding the (already installed) python program). My Linux Gentoo Distri has dicarded Pythoncard, so I'm kind of stuck.
Rüdiger
On my window vista laptop, the python stuff doesn't install properly (wxpython complains not finding the (already installed) python program). My Linux Gentoo Distri has dicarded Pythoncard, so I'm kind of stuck.
Rüdiger
not really a windoze expert, but... is it in the PATH? have you rebooted windows after python installation?On my window vista laptop, the python stuff doesn't install properly (wxpython complains not finding the (already installed) python program).
you may try to build it from sources... or get rid of Gentoo and move to another distro. 😛My Linux Gentoo Distri has dicarded Pythoncard, so I'm kind of stuck.
BTW: why has pythoncard been dicarded? It's still in Debian, so I guess there should be no licence or maintenance/compatibility issues... 😕
- Home
- Source & Line
- Digital Source
- Open-source USB interface: Audio Widget