[hpsdr] Good Ubuntu audio advice from Roger Rehr
Richard Ames
richard at ames.id.au
Wed Aug 11 23:23:19 PDT 2010
-------- Forwarded Message --------
From: w3sz <73w3sz at gmail.com>
Reply-to: dttsp-linux at yahoogroups.com
To: dttsp-linux at yahoogroups.com
Subject: [dttsp-linux] Audio gotchas...taken from alex188's thread
Date: Thu, 12 Aug 2010 01:09:39 -0400
Hi Alex,
Fortunately, you do NOT need to modify the ghpsdr client to get audio
output from the Ubuntu machine's speakers to work. I do get Ubuntu
speaker audio out of the ghpsdr[3] client here by doing what another
poster recommended that you do...add the option --local-audio 1 to the
command line when you start it....e.g.:
/ghpsdr3/trunk/bin$ ./ghpsdr --local-audio 1
I HAVE in the past before taking the steps noted below gotten the same
error message that you reported, "open of local audio device failed:
Device or resource busy" and was able to get rid of it as noted below.
The error IS due to the device being busy. This is an example of an
error message that actually points to the problem in a way that
benefits
the user! ;)
IF you have any other process running that has in the past or is
currently claiming the audio device that ghpsdr wants, you will see [as
I am sure you know all too well] when you start ghpsdr[3]:
gHPSDR rx 0 (Version 0.3)
setup_system_audio: sdr-7591-0
setup_system_audio: sdr-7591-1
ozy_init: command bound to port 12000 socket 6
ozy_init: server 127.0.0.1
send_command: command='attach 0'
send_command: response='OK 48000'
connect: sampleRate=48000
setSpeed 0
send_command: command='start iq 13000'
send_command: response='OK'
ozy_init: spectrum bound to port 51250 socket=8
spectrum_thread: socket 8
open_local_audio
open of local audio device failed: Device or resource busy
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I can say from personal experience that you will get this message for
example,
1. if you still have firefox open even if it is not currently playing
any audio.
2. if you have the PulseAudio Volume Control open
3. if you have gnuradio-companion open if you had been playing audio
with it, even if it is not playing audio at present and the .grc file
that you had been running is NOT running.
4. If you have open pretty much any application that is playing audio
at the current time or was in the past, etc. etc. I have not yet found
another application that uses the audio output stream that I CAN have
running when I try to start up ghpsdr[3].
You will however NOT get the aforementioned error message merely as a
result of having PulseAudio installed, as I have PulseAudio installed
and running with no problems caused by it that prevent Ubuntu speaker
output from ghpsdr[3], qtMonitor, gnuradio, etc. With pulseaudio
sleeping in the background, ghpsdr[3] [and qtMonitor and gnuradio...]
will happily start and play Ubuntu speaker audio with no problem. But
as
noted above, having the PulseAudio Volume Control running will cause
problems in starting up the ghpsdr[3] application, for example.
So I think Andrea was exactly right, and that SOMETHING is claiming the
audio channel at your site at the time you are starting ghpsdr[3] and
that is the reason for your problem. You may not even be aware that the
process is running, as it may be in the background and even asleep.
Look at your list of current processes for example by using the Ubuntu
'system monitor' from the pulldown System>>Administration menu and
start
closing 'the usual suspects' until ghpsdr is able to claim the audio
stream. Remember that even a process marked 'sleeping' that is not
currently playing audio may be the culprit.
Once you have closed the offending application, when you start
ghpsdr[3]
you will be greeted with a different set of messages than before.
If you are successful you will then see:
gHPSDR rx 0 (Version 0.3)
setup_system_audio: sdr-7608-0
setup_system_audio: sdr-7608-1
ozy_init: command bound to port 12000 socket 6
ozy_init: server 127.0.0.1
send_command: command='attach 0'
send_command: response='OK 48000'
connect: sampleRate=48000
setSpeed 0
send_command: command='start iq 13000'
send_command: response='OK'
ozy_init: spectrum bound to port 51250 socket=8
spectrum_thread: socket 8
open_local_audio
output_sample_increment=1 <<<<<<<good news starts here!!
send_command: command='frequency 7042651'
send_command: response='OK'
getSoundcardId: HPSDR id=8
setSoundcard: 8
setSoundcard -11.000000 -25.000000
iphone_thread
audio_stream_thread
send_command: command='frequency 7054351'
send_command: response='OK'
Success!!
By the way, here at w3sz, at least, there is a bug in the current
ghpsdr[3] client in that when I turn on the external audio I can no
longer click tune the client's frequency by clicking on the spectrum.
The frequency numbers and labels on the graphs change, but the actual
received frequency and the peak positions on the spectrum and waterfall
displays do not. Both the client and the server think all is well in
this regard, exchanging messages like the below, but the frequency
doesn't change:
send_command: command='frequency 7100000'
send_command: response='OK'
send_command: command='frequency 7087651'
send_command: response='OK'
send_command: command='frequency 7093351'
send_command: response='OK'
and
parse_command(Rx0): 'frequency 7100000'
response(Rx0): 'OK'
parse_command(Rx0): 'frequency 7087651'
response(Rx0): 'OK'
parse_command(Rx0): 'frequency 7093351'
response(Rx0): 'OK'
This is not a complaint, just a note for those who try this at this
time.
Finally, I will add that of course the audio output for qtMonitor
behaves the same way when you start qtMonitor, in that you cannot have
another audio device running when the qtMonitor application attempts to
grab the audio at startup, or you get the same 'device or resource
busy'
error. You CAN start the Pulse Audio Volume Control application once
qtMonitor [or ghpsdr[3] is running and both the Volume Control and the
receiver will continue to function. Or you can restart Firefox and
listen to that killer band on YouTube with no adverse effect on
ghpsdr[3] when ghpsdr[3] is already running, but if you exit the
receiver and try to restart it, you will need to kill the Volume
Control, Firefox, etc. first.
These pecularities are NOT the fault of the individual HPSDR
applications. They are a function of the Ubuntu base audio system. But
you need to know about them to use the applications in which we are
interested without getting very frustrated.
Of course, getting audio output from your speakers may require that you
know which audio device actually gives output to your speakers, so that
you can set things up appropriately. If you select the wrong device for
speaker output, you will get no speaker output. I can for example
select the digital output of my HDA Intel audio device [hw:1,0] instead
of the analog output [hw:0,0], as my default device, and everything
will
seem to work with whatever application I am using in that I will get no
error messages, but I will get no speaker or headphone output.
There is a 'gotcha' in that when your default audio output device is
'taken' by another process and you get the error message noted above,
you will likely find that other output devices which are not used by
the
system with default settings will 'seem' to work [since no devices are
using them] and will generate no error messages, but they will give you
no audio output. So you may be led AWAY from the correct device! You
can find out what audio devices are installed and recognized on your
system by doing aplay -l or cat /dev/sndstat or cat /proc/asound/cards,
for example, as you probably know. Then work thru the devices to find
'the right one' to use if need be.
I suppose I should close by saying that I have jack and its pulse-audio
module installed, but I have not invoked them for these purposes. So
they do not enter into the issues here.
As I am sure that you and others are also interested in playing with
qtMonitor, and since I mentioned it above, I might as well also say
that
I have been able to get [somewhat bumpy] Ubuntu speaker audio output
from qtMonitor by changing line 239 in qtMonitor.cpp to
widget.audioComboBox->setDisabled(FALSE);
and recompiling, and then choosing 'pulse' as the audio output device
on
the qtMonitor GUI.
If you try to compile and run qtMonitor, don't forget Andrea's
important
notes [slightly modified and appended by me]:
---------------------------------------
To successfully recompile this code (Ubuntu 10.04) define a
QMAKE environment variable pointing to the local qmake:
cd ~/N6LYT/ghpsdr3/branches/qt
export QMAKE=/usr/bin/qmake-qt4
make clean && make
A (very) minor issue left in qtmonitor is that the 'make all' command
fails when compiling main.cpp for Release, due to a missing
-I/usr/include/qt4/QtNetwork in the file
/ghpsdr3/branches/qt/qtMonitor/qt-Release.mk Add this missing element
to this file.
qtMonitor will connect to DSPSERVER which is also connected to SERVER.
So you need both dspserver and server running to run qtMonitor [or at
least I do].
start server with: ./server
then start dspserver with ./dspserver --receiver 0 --server 127.0.0.1
or
equivalent
then start qtMonitor with ./qtMonitor
------------------------------------
I hope the above was helpful.
If you want more info from me, feel free to contact me on or off the
list. I am sure there are others with more knowledge too, and I would
love to learn, as always...
73,
Roger Rehr
W3SZ
On 08/11/2010 10:27 PM, Alex wrote:
>
>
> --- In dttsp-linux at yahoogroups.com, andrea
montefusco<andrea.montefusco at ...> wrote:
>>
>> On Wed, Aug 11, 2010 at 5:26 PM, Alex<lee188 at ...> wrote:
>>> open of local audio device failed: Device or resource busy
>>
>> Is the firefox or some other application (audio aware) running ?
>> I had a similar issue with GNU Radio.
>>
>> *am*
>>
>> --
>> Andrea Montefusco IW0HDV
>>
>
> Hi Andrea,
>
> firefox was not running.
>
> The problem is with the sound setup in my Ubuntu 10.04 PC.
>
> The softrock server seems to be able to access the various alsa
devices, including those from jackd. However, the ghpsdr client seems to
be using oss, ie /dev/dsp still. I know that the oss emulation support
in Ubuntu 10.04 is not very good - had a bad experience when installing
linrad. Luckily linrad can use alsa natively instead of oss.
>
> Instead of fooling with oss emulation and getting /dev/dsp to work, I
may have a look at the ghpsdr client and change it to using alsa.
>
> 73 Alex
More information about the Hpsdr
mailing list