xmms blocks sound device

[Wade Chandler]

thedogfarted wrote:

> 
> 
> Wade Chandler wrote:
> 
>> thedogfarted wrote:
>>
>>> i noticed one more interesting thing - i can listen to xmms and 
>>> cdplayer in the same time... cdplayer continues to play even after 
>>> the system is halted
>>>
>>> thedogfarted wrote:
>>>
>>>> Hi
>>>>
>>>> I installed Fedora Core 1 today and got bad surprise - et failed to 
>>>> start because xmms was blocking the soundcard. My previous os was 
>>>> freeBSD 5.2 and then i was able to play et and listen to xmms
>>>>
>>>> pls give me some advice...
>>>>
>>>>
>>>
>>>
>> What sound server are you using? 
> 
> 
> where can i see it? xmms is using oss plugin, configured with /dev/dsp 
> audio device and /dev/mixer mixer device
> 
>> Artsd is one example of a sound server.  This is an area where the 
>> linux community has to come together.  The standard sound system works 
>> the way you are describing.
>>
>> You can use ALSA or Arts for your sound.  If you are are using Artsd 
>> you can change the output of XMMS to use the artsd plugin.  Artsd will 
>> allow multiple sound outputs.  artsdsp will start my app and redirect 
>> my sound system calls to artsd.  If you don't have this plugin by 
>> default you can download it from the xmms home page.
> 
> 
> I'll look for the plugin. I think have alsa but i need more free time to 
> look at the docs.
> 
>> Sometimes, but not as often as I believe it should work, you can use 
>> artsdsp for you sound.  artsdsp will run your application for you 
>> redirecting sound system calls to arts.  Lets say I have an app call 
>> playmysounds.  I would do this:
>> artsdsp playmysounds
>> artsdsp will find my app on the path and run it as a child process 
>> redirecting sound lib calls.
>>
>> What we need is a multi process kernel level sound system for 
>> /dev/dsp.  This means we need another layer of abstraction between the 
>> sound driver and the device files I believe.  Currently it does not 
>> spool in the manner the sound servers do.  I like to write java 
>> applications as well as C apps, but my java apps have to use the 
>> standard sound services for sound output.  Thus, my apps block the 
>> sound device, or they don't output sound because of another 
>> application hogging the device.
> 
> 
> hmmm... my only java app that uses sound works ok
> 
>>
>> You best bet with XMMS is to use something like artsd and then to set 
>> XMMS to use the artsd plugin for sound output.  KDE makes using Artsd 
>> very easy from the control panel.
> 
> 
> I'm using GNOME :)
> 
>>
>> Wade
>>
>>
>>
> 
> 
Exactly,

Your java app works because you are using the standard sound system. I 
believe this to be the case because the way you described XMMS working. 
  Mine works like that too, but not if I'm running a sound server which 
hogs the sound device wanting other apps to use it for output that the 
vm doesn't have a plugin for.  The JVM doesn't have Artsd plugins or 
drivers.  It behaves like XMMS by default.  I have java apps that use 
sound and work fine as long as I'm not streaming sound in XMMS or 
something else.  Thus the crux of the matter.  If you write a program 
that doesn't have plugins for the enumerous different sound servers then 
you are limiting your user, but it is a major effort to support 
different sound api's and keep everything up to date, so without a 
standard it is limiting to developers.  That was why I mentioned the 
need to unify and address this issue in the Linux community.  I think 
the 2.6 kernel may be trying to do this exact thing, but I'm not sure yet.

Wade