# Audio Source configuration **URL:** \ **Category:** GNU Radio\ **Created:** [March 17, 2015, 3:32pm UTC](https://www.ruby-forum.com/t/audio-source-configuration/234608 "2015-03-17T15:32:12Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![addis\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c4cdca/32.png) [@addis\_a](https://www.ruby-forum.com/u/addis_a)\ **Post date:** [March 17, 2015, 3:32pm UTC](https://www.ruby-forum.com/t/audio-source-configuration/234608/1 "2015-03-17T15:32:12Z")
Hello: Can anyone point me to some “color” on how to work with the Audio Source. I am working examples to transmit FM Audio and have problems with Underruns on the UHD:USRP Sink. The examples (from [files.ettus.com/tutorials/Lab\_5.grc](http://files.ettus.com/tutorials/Lab_5.grc) and others) I am running select Audio Source Arch:alsa and this seems to be a problem. I have tried to replace the Device name with plughw:0,0 as suggested in the documetnation, but this does not seem to have an impact on the choice of Audio arch: alsa If I replace the audio source with a signal source at the same sample rate all is well, but the Audio Source implements UUUUUUUUUUUU. Using the suggestion of having the USRP expect a bit lower rate than the audio can deliver seems to implement nearly limitless delay … the voice is received but only after a very long … many seconds delay … … At this time I am using a B210 connected via USB3 to an I7 with plenty of memory running Ubuntu 12.04 … I have similar issues trying to use an E310 as the transmitter … Any direction would be appreciated. LVDJ ---
**Author:** ![larryj](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/e480ec/32.png) [@larryj](https://www.ruby-forum.com/u/larryj)\ **Post date:** [March 17, 2015, 3:50pm UTC](https://www.ruby-forum.com/t/audio-source-configuration/234608/2 "2015-03-17T15:50:04Z")
If you’re getting long strings of ‘U’, this means a _gross_ sample-rate mis-match somewhere in your flow-graph, rather than the more-subtle “two clock” problem. Make sure that everything agrees internal to the graph about sample-rates, and, perhaps more importantly, that your audio _hardware_ is capable of delivering the desired rates. On 2015-03-17 10:30, Larry Van Der J. via USRP-users wrote: > Using the suggestion of having the USRP expect a bit lower rate than the audio > can deliver seems to implement nearly limitless delay … the voice is received > but only after a very long … many seconds delay … … > [http://lists.ettus.com/mailman/listinfo/usrp-users\_lists.ettus.com](http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com) [1] > Links: ---
**Author:** ![larryj](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/e480ec/32.png) [@larryj](https://www.ruby-forum.com/u/larryj)\ **Post date:** [March 17, 2015, 4:19pm UTC](https://www.ruby-forum.com/t/audio-source-configuration/234608/3 "2015-03-17T16:19:52Z")
Hi Larry, if I understand correctly, then you’re using the audio source as “input” to your usrp\_sink-terminated flow graph. In that case, the "U"nderruns come from UHD, not the audio source; the flow graph is not supplying samples fast enough. The problem might be systematic, for example if the rate change in your flow graph does not reflect the actual rate ratio between your audio device and the USRP – e.g. the your audio device generates samples at 48kS/s, and your USRP consumes them with 5MS/s, but you have an interpolation rate of 100 (leading to a rate at which samples arrive at the USRP sink of 4.8MS/s; these are all just exemplary numbers). Also possible, though, is that this is simply an extreme case of clock mismatch: For example, assume the reference clock in your USRP is of by 2ppm, making the “sample consume rate” (1+2e-6) times higher than it should be, according to an imaginary “exact” clock. Now, assume your sound card is a bit “slower” than it should be, so let these should-be 48kS/s be (1-500e-6) times that what it should be. That means that for every a USRP sampling rate of let’s say 5MS/s, you’d have around 2500 samples too little per second, which (there’s around 250 samples transportable per USB packet) is around 10 sample packets less than the USRP consumes. Greetings, Marcus [1] I pulled up the first sound chip datasheet I could find (TI PCM2903), and it demanded ±500 ppm. ---
**Author:** ![larryj](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/e480ec/32.png) [@larryj](https://www.ruby-forum.com/u/larryj)\ **Post date:** [March 17, 2015, 4:27pm UTC](https://www.ruby-forum.com/t/audio-source-configuration/234608/4 "2015-03-17T16:27:31Z")
Maybe watch your CPU utilization with htop when you’re recording with terminal command to /dev/null, and compare it to gnuradio with a null source. If you take out or disable the audio source, the underflows should go away. On Tue, Mar 17, 2015 at 5:14 PM, Marcus Müller [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) ---
**Author:** ![larryj](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/e480ec/32.png) [@larryj](https://www.ruby-forum.com/u/larryj)\ **Post date:** [March 17, 2015, 4:43pm UTC](https://www.ruby-forum.com/t/audio-source-configuration/234608/5 "2015-03-17T16:43:39Z")
Thanks for reaching out, all input is appreciated. The file in use is from [files.ettus.com/tutorials/Lab\_5.grc](http://files.ettus.com/tutorials/Lab_5.grc). The “gross” mismatch in sample rates comes about when you set the Rational resampler output rate to be exactly what the UHD:USRP Sink is expecting … in this case 250K. The incidence of UUU’s is reduced when you introduce the fudge factor suggested at 1.1 in that there is only a short string of approximately 30 U’s on startup, but the delay between speaking and transmitting grows from nearly instantaneous at the start of a test to countable numbers of seconds within a short period of time, presumably because there is a buffer involved that is being drained more slowly than it is being filled … The OK to Block setting in the Audio Block seems to have no influence (this is as expected since it is noted in the text of the tutorial that ALSA is unaffected by this setting). Least anyone think that delays on the order of a few seconds are not a problem, I note that in applications intended to improve indoor coverage, delays between the direct path of the outdoor signal and the enhanced path from the regenerative equipment are critical to operation and need to be on the order of 10s of microseconds for the equipment to function correctly. Any thoughts on how to troubleshoot the Audio Source or determine alternates to ALSA would be much appreciated. Thanks again, 73 LVDJ ---
**Author:** ![larryj](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/e480ec/32.png) [@larryj](https://www.ruby-forum.com/u/larryj)\ **Post date:** [March 19, 2015, 7:33pm UTC](https://www.ruby-forum.com/t/audio-source-configuration/234608/6 "2015-03-19T19:33:46Z")
Hello: Thanks to everyone who has replied. It seems that audio processing has some sort of timing issues. When I experiment with the channelizers detailed in; > **[PFB Channelizers and Synthesizers — Rondeau Research](http://www.trondeau.com/examples/2014/1/23/pfb-channelizers-and-synthesizers.html)** > > Building the Filters > Based on the paper presented at the  Karlsruhe Institute of Technology's  Workshop on Software Radio (WSR). > The paper starts off by explaining how to build the prototype filters and how these lead directly to the... [https://static.squarespace.com/static/543ae9afe4b0c3b808d72acd/543aee1fe4b09162d08633d9/543aee20e4b09162d086354d/1395272342027/fm\_channelizer.grc](https://static.squarespace.com/static/543ae9afe4b0c3b808d72acd/543aee1fe4b09162d08633d9/543aee20e4b09162d086354d/1395272342027/fm_channelizer.grc) With the only change being setting the Mb0 clock source to default rather than as in the demo in order to get the flowgraph to run on my E310 as well as my B210, The B210 is running on an Ubuntu 12.04 kernel 3.8.0-44-generic, the E310 is running 3.14.2-xilinx. I find that the code runs with minimal aU and O on the B210 connected using USB3 to an I7 machine. However, when I I try the exact same code Xed in to my E310 running the Dizzy Demo image with updates to allow for QTGUI and QWT to operate, There are very many string of approximately 30 Os interspered with single aUs and these overflow result in completely broken unusable audio. I am now researching what levers may be available for audio system tuning and into the possibility of switching to Jack for audio … As always any links or pointers are welcomed. LVDJ On Tue, Mar 17, 2015 at 10:30 AM, Larry Van Der J. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)