The security update in Bug 11305 describes this in detail. $ nasd -d 3 Network Audio System Release 1.9.3 Network Audio System Release 1.9.3 AuInitPhysicalDevices(); Init: will close device when finished with stream. Init: will keep mixer device open. Init: Leaving the mixer device options alone at startup. Init: openDevice OUT /dev/dsp mode 1 Init: Output open(/dev/dsp) failed: No such file or directory Fatal server error: could not create audio connection block info Once ossp is installed and rebooted it creates /dev/dsp and nas can be then be started with the -np option. Reproducible: Steps to Reproduce:
should say -pn option :\
Keywords: (none) => TriagedCC: (none) => luigiwalser, oe
I have /dev/dsp and I don't have ossp installed. Do you actually have a sound card in the system you tested on? I'm not sure what's responsible for creating /dev/dsp these days (udev I'd hope) or the mechanics for that. ossp is just one possible way to provide it.
CC: (none) => mageia
$ ls -1 /dev|grep ^d disk/ No /dev/dsp here either, and I'm currently listening to http://www.aljazeera.com/watch_now/ After skimming the kernel source, it's created by modprobe snd-pcm-oss Claire, and you retest with ossp removed, and the module snd-pcm-oss loaded, to see if that's enough?
CC: (none) => davidwhodgins
I just checked my Virtualbox VMs and they also have /dev/dsp and snd-pcm-oss is loaded. I'm not sure if anything special needs to be done to turn these on; I don't remember doing anything and I don't see any references to oss in /etc/modprobe*. Anyway, it seems that something is wrong with the configuration of the system you tested on, I'm just not sure exactly what. Colin probably would know.
Status: NEW => RESOLVEDResolution: (none) => INVALID
Every system, mga3 installs 64 and 32bit and vbox mga2 installs 32 and 64bit and also Bullrich tried testing nas on mga2 64 hw install and had the same thing. Re-opening.
Status: RESOLVED => REOPENEDResolution: INVALID => (none)
And Dave too in comment 3 btw.
(In reply to Dave Hodgins from comment #3) > $ ls -1 /dev|grep ^d > disk/ > > No /dev/dsp here either, and I'm currently listening to > http://www.aljazeera.com/watch_now/ > > After skimming the kernel source, it's created by > modprobe snd-pcm-oss > > Claire, and you retest with ossp removed, and the > module snd-pcm-oss loaded, to see if that's enough? Indeed Dave yes. # ls /dev/ds* ls: cannot access /dev/ds*: No such file or directory # modprobe snd-pcm-oss # ls /dev/ds* /dev/dsp /dev/dsp2
Well I don't think anything is wrong with the nas package, but I don't understand why your systems don't have snd-pcm-oss loaded.
(In reply to David Walser from comment #8) > Well I don't think anything is wrong with the nas package, but I don't > understand why your systems don't have snd-pcm-oss loaded. snd-pcm-oss conflicts with osspd. osspd is preferred under PulseAudio to alsa emulation (which blocks the sound card). Hence snd-pcm-oss is only loaded when using the alsa sound profile.
(In reply to Colin Guthrie from comment #9) > (In reply to David Walser from comment #8) > > Well I don't think anything is wrong with the nas package, but I don't > > understand why your systems don't have snd-pcm-oss loaded. > > snd-pcm-oss conflicts with osspd. osspd is preferred under PulseAudio to > alsa emulation (which blocks the sound card). Hence snd-pcm-oss is only > loaded when using the alsa sound profile. No, the issue was that she didn't have it when osspd wasn't installed.
(In reply to David Walser from comment #10) > No, the issue was that she didn't have it when osspd wasn't installed. AS mentioned above, it relates to which sound profile is selected (e.g. see update-alternatives --display soundprofile). This is independent of whether osspd is installed or not. osspd is hence needed if you're using Pulse and want OSS but it's not mandatory (OSS is, after all, deprecated). Namely this is the /etc/sound/profiles/alsa/snd-oss.conf file which is ultimately symlinked to /etc/modprobe.d/snd-oss.conf (although of course if the (default) pulse soundprofile is selected, then it'll be /etc/sound/profiles/pulse/snd-oss.conf that gets used).
(In reply to Colin Guthrie from comment #11) > (In reply to David Walser from comment #10) > > No, the issue was that she didn't have it when osspd wasn't installed. > > AS mentioned above, it relates to which sound profile is selected (e.g. see > update-alternatives --display soundprofile). This is independent of whether > osspd is installed or not. osspd is hence needed if you're using Pulse and > want OSS but it's not mandatory (OSS is, after all, deprecated). > > Namely this is the /etc/sound/profiles/alsa/snd-oss.conf file which is > ultimately symlinked to /etc/modprobe.d/snd-oss.conf (although of course if > the (default) pulse soundprofile is selected, then it'll be > /etc/sound/profiles/pulse/snd-oss.conf that gets used). So it was a configuration issue? How did this happen to her? Also, should we close this bug?
It's simply that ossp is not installed. If you want oss sound and you use PA then you need to install ossp. It should be suggested by something or other (I actually thought it was required by soundwrapper, but it seems not). soundwrapper knows about osspd, but looking at it, it doesn't seem to require it or suggest it. That said, soundwrapper itself is now only required by a handful of pkgs: gnome-speech-driver-espeak kino mplayer-gui soundwrapper stepmania I would argue the mplayer-gui one is bogus (mplayer has native PA support), and I thought stepmania was an SDL game which would use SDL_mixer and thus PA. (perhaps it doesn't use the SDL sound tho'). I suspect espeak uses gstreamer and that leaves only kino which is pretty dead these day I think (kdenlive being preferred) and checking their website at kinodv.org confirms this. Anyway, it seems osspd is not really pulled in by much and soundwrapper could be almost unneeded shortly, I'm not sure what I'd suggest as a resolution. Perhaps we can require it in soundwrapper for mga4? Obviously nasd doesn't require soundwrapper which is generally bad (as it'll have all the problem associated with OSS sound regarding device locking) but as it's not launched via a .desktop file it would need it's binary replaced with a wrapper script anyway. That said I don't like requiring osspd with soundwrapper. I'd rather it wasn't installed. I *could* make osspd service dependent on the soundprofile so it doesn't start under alsa, but it *is* still useful in that case too, so I don't really want to do that. There isn't really a *correct* place to require it sadly. pulseaudio-client-config is an option, but again, it's not strictly speaking "required"...
Well, osspd shouldn't be required, as under normal circumstances /dev/dsp should work fine without it. It sounds like you're saying once you install osspd, you won't have /dev/dsp until osspd is actually running, but in Comment 0 it sounded like she didn't have it before she installed the package. Maybe draksound should just make sure you have some sort of working configuration, whether that means snd-pcm-oss or osspd. As for soundwrapper (one of the smallest programs, but probably one of my biggest contributions to Mandrake :o), maybe our goal should be to have nothing left requiring it anymore for mga5 and have it be deprecated (keeping it around in case people are using it with third party stuff that still needs it) and maybe removing it in mga6?
(In reply to David Walser from comment #14) > Well, osspd shouldn't be required, as under normal circumstances /dev/dsp > should work fine without it. Not really true. To use /dev/dsp with a PulseAudio sound profile the only supported method is going via ossp. If you run your app via soundwrapper, it'll use library hijacking to catch the open calls to /dev/dsp (which won't exist) and pass it to PA via padsp or similar. While this half works, it's not really how we would recommend it works as it still has some drawbacks (being a generally nasty technique being the main one). > It sounds like you're saying once you install osspd, you won't have > /dev/dsp until osspd is actually running Not quite. As mentioned above, installing osspd or not is mostly irrelevant. It's to do with the currently active sound profile which controls the modprobe.d snippets which controls the creation or otherwise of /dev/dsp and friends. In the case of a "pulse" sound profile it's osspd that creates the device nodes as cuse user-space character devices. > but in > Comment 0 it sounded like she didn't have it before she installed the > package. Correct. This is because she is using a pulseaudio sound profile. This is effectively a defence mechanism. Using oss emulation can appear to work but cause other problems (hogging the sound device being the main one: which would have happened in this case), so when PA is used, it basically refuses to offer the opportunity to break things like this and mandates that if you want to have OSS sound then you basically have to use osspd (although soundwrapper/padsp will kinda work too, but is not officially supported). > Maybe draksound should just make sure you have some sort of working > configuration, whether that means snd-pcm-oss or osspd. Well..... it's kinda a user choice. If I don't have any OSS apps why should I run osspd daemon? If we want to insist on this, we could just require it in pulseaudio-client-config and we should be fine. I guess if users are really against it they can mask the service. Perhaps that's the easiest way to make this work without user interaction? > As for soundwrapper (one of the smallest programs, but probably one of my > biggest contributions to Mandrake :o), maybe our goal should be to have > nothing left requiring it anymore for mga5 and have it be deprecated > (keeping it around in case people are using it with third party stuff that > still needs it) and maybe removing it in mga6? Indeed a very useful utility :) Well, I think we should basically default to ossp for both alsa and pulse (it has proxies for both), and thus it wouldn't be required any longer, even with third party stuff (in fact it would work even better with third party stuff as there would be no need to modify it in any way) - I've not tested it too much with plain alsa tho', so can't really comment on how well it works. To be honest, I should really have done this for mga4, but basically forgot! :s
(In reply to Colin Guthrie from comment #15) > (In reply to David Walser from comment #14) > > Maybe draksound should just make sure you have some sort of working > > configuration, whether that means snd-pcm-oss or osspd. > > Well..... it's kinda a user choice. If I don't have any OSS apps why should > I run osspd daemon? If we want to insist on this, we could just require it > in pulseaudio-client-config and we should be fine. I guess if users are > really against it they can mask the service. Perhaps that's the easiest way > to make this work without user interaction? That's one option. The other is have the installer and draksound install osspd when you switch to (or default to in the installer's case) the pulseaudio sound profile. That would also allow you to then just uninstall it if you don't want it. > > As for soundwrapper (one of the smallest programs, but probably one of my > > biggest contributions to Mandrake :o), maybe our goal should be to have > > nothing left requiring it anymore for mga5 and have it be deprecated > > (keeping it around in case people are using it with third party stuff that > > still needs it) and maybe removing it in mga6? > > Indeed a very useful utility :) > > Well, I think we should basically default to ossp for both alsa and pulse > (it has proxies for both), and thus it wouldn't be required any longer, even > with third party stuff (in fact it would work even better with third party > stuff as there would be no need to modify it in any way) - I've not tested > it too much with plain alsa tho', so can't really comment on how well it > works. > > To be honest, I should really have done this for mga4, but basically forgot! > :s Yes I remember us talking about that at some point :o)
Mageia 3 changed to end-of-life (EOL) status 4 months ago. http://blog.mageia.org/en/2014/11/26/lets-say-goodbye-to-mageia-3/ Mageia 3 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Mageia please feel free to click on "Version" change it against that version of Mageia and reopen this bug. Thank you for reporting this bug and we are sorry it could not be fixed. -- The Mageia Bugsquad
Status: REOPENED => RESOLVEDResolution: (none) => OLD