[nas] No love (could not create audio connection block infowhen starting)
nick at ing-simmons.net
Wed Sep 15 06:21:05 MDT 2004
Jon Trulson <jon at radscan.com> writes:
>> So basically, I've had sporadic at best results, following intuition and
>> Every now and again I can get nasd to start, but it either doesn't play
>> or complaints that /dev/dsp is busy.
> Only one app can be accessing the audio device at a time.
This seems not to be true with ALSA and OSS emulation.
OSS opens a "plug" device and that gets mixed with other sources.
(At least on my hardware.)
That said on SuSE8.3/SuSE9.0 the ALSA OSS emulation seemed fragile,
but seems ok on SuSE9.1 (2.6 kernal and ALSA 1.x)
>when running, and in it's default configuration, will always release the
>device when a flow is completed. This way it does not hog
> Unfortunately esound, arts, etc do not. They expect to own the
>device the entire time they are running.
> You might try something like 'fuser -v /dev/dsp' next time that
>happens to see what process is holding the device open...
>> I use Redhats cheesy little "detect
>> device" applet, and it always detects the device, and is able to play the
>> even when NASD thinks it's busy.
> Is the rh applet merely sending it's audio to
>esound/artsd/whatever rather than to the device directly? If so, and one
>of those is the culprit holding the device open, then yes, that would work
>would it not? :)
> try running strace on nasd when this happens.. something like:
> strace -o/tmp/out nasd -aa -v -d 99
> Then see if anything interesting is in /tmp/out.
>> The only thing consistent is when I run arts :x -aa,
> nasd you mean?
>> /tmp/.sockets/audiox will be created, meaning I can't use that port anymore.
> Why? as long as another process (ie: another nasd) isn't bound to
>that socket, the new nasd will just re-use it... Otherwise, if it is
>bound to someone else, you will get something like an 'address already in
> BTW... What version of NAS are you running?
More information about the Nas