Tested amsn-0.98.4-9.mga2 on Mageia release 2 (Cauldron) for x86_64 Kernel 3.3.0-server-2.mga2 on a Dual-processor x86_64 / \l In the preferences of amsn, it is impossible to configure the webcam and also the sound. He said no device found (whether sound or as a webcam) In console : $ amsn Unable to open mixer /dev/mixer For info : On mageia 1 for x86_64 ,there is no problem ,everything works fine
CC: (none) => sander.lepikAssignee: bugsquad => jani.valimaa
is it configured to use pulseaudio ?
Source RPM: (none) => amsn
Could you try amsn from mga1?
Ok, # urpme amsn désinstallation de amsn-0.98.4-9.mga2.x86_64 désinstallation du paquetage amsn-0.98.4-9.mga2.x86_64 ------------------------------------------------------------ # LC_ALL=C urpmi --test rsync://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/1/x86_64/media/core/release/amsn-0.98.4-3.mga1.x86_64.rpm A requested package cannot be installed: amsn-0.98.4-3.mga1.x86_64 (due to unsatisfied libtk8.6.so.0()(64bit)) I will try rebuilder the srpm package,What do you think?
Created attachment 1941 [details] Error during rebuild fot the srpm amsn-0.98.4-3.mga1.src.rpm So I tried to rebuild the srpm package but there is an error ,here the attachement:
No news for this problem?
I can reproduce this, but I have no idea what causes it. :(
Hi, This bug was filed against cauldron, but we do not have cauldron at the moment. Please report whether this bug is still valid for Mageia 2. Thanks :) Cheers, marja
Keywords: (none) => NEEDINFO
After a new fresh install for Mageia 2 with the Mageia-2-x86_64-DVD, I can confirm that the bug is always present for me.
Version: Cauldron => 2
Keywords: NEEDINFO => (none)Summary: aMSN-0.98.4 on mageia 2 beta 2 does not recognize any devices => aMSN-0.98.4 does not recognize any devices
(In reply to comment #7) > I can reproduce this, but I have no idea what causes it. :( Can you provide amsn-0.98.9 to update_testing to fix this bug?
CC: (none) => mageia
(In reply to comment #10) > (In reply to comment #7) > > I can reproduce this, but I have no idea what causes it. :( > > Can you provide amsn-0.98.9 to update_testing to fix this bug? Does it fix this bug in Cauldron?
For my part, yes.
I can confirm that missing /dev/mixer appears to be a bug in 32bit Mageia 2 as well and it is screwing up a number of apps. I *think* /dev/mixer gets created by ALSA? Perhaps this is an ALSA bug?
CC: (none) => george
Pushed new amsn 0.98.9 to core/updates_testing, please test it.
Testing for the srpm amsn-0.98.9-0.1.mga2.src.rpm in Core_Updates_Testing ,it doesn't work better. --------------------------------------------------------------- $ amsn Unable to open mixer /dev/mixer ioctl: VIDIOC_S_CTRL(id=9963776;value=96): Invalid argument ioctl: VIDIOC_S_CTRL(id=9963777;value=2): Invalid argument ioctl: VIDIOC_S_CTRL(id=9963779;value=2): Invalid argument ioctl: VIDIOC_S_CTRL(id=9963778;value=6): Invalid argument ioctl: VIDIOC_S_CTRL(id=9963776;value=96): Invalid argument ioctl: VIDIOC_S_CTRL(id=9963777;value=2): Invalid argument ioctl: VIDIOC_S_CTRL(id=9963779;value=2): Invalid argument ioctl: VIDIOC_S_CTRL(id=9963778;value=6): Invalid argument ---------------------------------------------------------------- The only devices that I can now parameterize is the Webcam but not mixer.
Look, The problem going on here is that amsn cannot find /dev/mixer. Why not just create /dev/mixer? /dev/mixer can be easily created with `modprobe snd-mixer-oss` Give it a try and see if this solution works. This problem started with the new kernel. I think the new kernel *should* be loading this and who knows how many other modules that it is NOT loading. - George
(In reply to comment #16) > Look, The problem going on here is that amsn cannot find /dev/mixer. Why not > just create /dev/mixer? /dev/mixer can be easily created with `modprobe > snd-mixer-oss` Colin, this module is blacklisted by sound-scripts. Is there some known workaround for such problems?
snd-mixer-oss is blacklisted because it apparently interferes with the use of osspd daemon which is *supposed* to eliminate the need for the oss modules. BUT osspd is NOT creating /dev/mixer which is causing problems for a NUMBER of legacy oss sound applications. I have seen suggestions that these applications simply be ripped out of the distro. That is *NOT* a solution. The best solution is to FIX osspd so that it *properly* emulates *all* legacy oss functions. Until then, we need the option to revert to legacy oss operation. This is just one more in a string of pulse audio fiascos. - George
This is EXACTLY what I mean: "The mixer behaves a bit differently tho. In the original OSS, /dev/mixer is the hardware mixer, so adjusting volumes there affects all audio streams. When using ossp, each process group gets its own mixer and the mixer always contains only two knobs - PCM and IGAIN. Combined with per-stream volume control of pulseaudio, this scheme works quite well for applications with embedded volume control although it makes standalone OSS mixer programs virtually useless[2]." From /usr/share/doc/ossp/README In all of its history pulse audio has been famous for breaking applications that many of us have depended on for years to solve problems that are now recurring and when we go to use the ONLY utilities that solve these problems we find out they have been neutered by pulse audio. At this point I am on the verge of ripping out pulse audio from my systems completely in order to deal with this mess. So if these tools don't get restored, that is probably the approach I will take with this whole thing. - George
This could ALL be fixed by moving the ossp related components recently added to sound-scripts over to the ossp package itself. That way, users who prefer to live without ossp until some of these issues are satisfactorily addressed would be able to simply remove the ossp package temporarily and get relief. Long term, I know that full pulse-audio implementation will be the solution to many sound problems in Linux. But at this point, it needs to find a better way to support legacy applications that require a hardware /dev/mixer. IN OTHER WORDS, at some point, pulse-audio needs to find a way to provide its OWN /dev/mixer device (and all the other OSS devices) that enable full access to the native hardware. The simple volume control/gain control only access that pulse currently provides simply doesn't cut it for all of us. In the mean time, we need a way to be able to "opt out" of this currently "one size fits all" solution. In the mean time, I have removed the ossp package and, regretfully, removed /etc/modprobe.d/snd-oss.conf. And now everything is working more normally for me. - George
The last several comments have been very ranty and pretty inaccurate (despite quoting from osspd documentation which clearly states that /dev/mixer support IS included) osspd DOES create a /dev/mixer and it works fine with applications that want to control the mixer internally. As an upstream pulseaudio maintainer I will categorically state that pulseaudio will never provide it's own /dev/mixer or /dev/dsp devices. This is osspd's job and it does that job fine. It's also not a goal to emulate *all* legacy API use cases. OSS sound is legacy and I strongly recommend not putting in a huge amount of effort to support it - that effort would be far better spent porting apps to use alsa or PA. For example I see zero point in supporting stand alone mixer applications going via OSS. There is no need to support this and it's also technically totally infeasible to give sufficient control anyway. Regardless of the above I could not reproduce any errors relating to /dev/mixer when running amsn here. Even if you do configure a cam and sound, just use /dev/dsp and /dev/mixer. Then use separate tools provided by the desktop environment to actually pick where you want the amsn streams to output to and record from. There are numerous tools for this in both GNOME and KDE, but you can always use pavucontrol for maximum interface. So some questions: Do you have any /dev/mixer device or does it simply not exist? If it does exist, is your user listed in the ACL for that device?
Ok,for me /dev/mixer doesn't exist simply.
Does restarting the osspd service create it?
Colin, I would not deny that my comments have been ranty. The reason for this is a long history of issues with pulse audio. Its a road I have been down before multiple times. Even Lennart Poettering called it "the software that currently breaks your audio" when it began to be adopted. I realize it has come a long way since then, and, as I noted in my most recent post, I DO believe it IS the FUTURE of Linux audio. But if ANYONE wants to run OSS, they should not be treated as a Windows user and arbitrarily and unnecessarily locked out of that option by the way sound is packaged. That is an elitist approach which I resent, and I would deeply appreciate it if you would rethink that aspect of it. From that point on, perhaps we could discuss ways in which pulse audio could be enhanced, such as giving the user the kind of customized hardware access to the actual sound device that even Windows provides. Or, if that option already exists, perhaps it could be more fully explained as to how to implement it. One issue I have, for example, is that in the past I could bring up an ALSA gui and get access to a huge array of controls and switches unique to my own sound card. Now the same gui brings up only two controls, basically output level and input level. What happened to all of the other options and how do I access them now? That is my question. - Thanks, George
I might add here that I was using osspd when all of this started, and the problem basically was no mixer file in the /dev directory. I would also suggest that David do a ps -afe to make sure that the ospd service is RUNNING after attempting to restart it. These are things I did not do and probably should have done. - George
Ok George, can you give me more details on what to do? because I did not understand.
David, I haven't got ossp installed right now, show I will have to demonstrate using pulse audio itself. First, as Colin instructed, you need to restart osspd. If you don't know how to do that, a fresh reboot should do the trick, assuming you have ossp installed. Then you need to do the following command while su'd to root to *ensure* that osspd is actually running: `ps -afe | egrep osspd` Below is an example doing the same thing with pulse audio: [root@localhost ghmitch]# ps -afe | egrep pulse ghmitch 3857 1 2 07:38 ? 00:04:54 /usr/bin/pulseaudio --start --log-target=syslog ghmitch 3864 3857 0 07:38 ? 00:00:00 /usr/lib/pulse/gconf-helper Note that when you execute the ps command, the response should indicate an osspd process in the output. There is always the possibility that osspd is crashing on our systems after starting for some reason unique to our own hardware. Verifying with a ps command will rule that out. - George
With my sound card, which lspcidrake lists as aVT8233/A/8235/8237 AC97 Audio Controller, I have to run pavucontrol, and on the configuration tab, change the internal audio profile from it's default to any one of the analog surround options.
CC: (none) => davidwhodgins
In my case, with pavucontrol, I am seeing the output as "Dummy Output". What I WANT to see is output to the specific audio device. - George
@George. You can still tweak the underlying controls, but in general it makes little sense to do so. The plethora of controls are beyond the ken of most users and they traditional approach was one of "fiddle with all of them until it works then don't touch it", which is just a mess. These days PA will control most of the common ones and allow you to switch profiles to use e.g. 5.1 surround, or digital outputs etc. via simple config GUIs that are provided by the various desktop environments, including speaker placement tests etc. PulseAudio may choose to control the volumes in interesting ways - for example if the "card" volume is 90% but you are playing only one stream that has an "app" volume of 50%, it doesn't make any sense to set the h/w to 90% and then attenuate the app in software to allow it to reach the 50% mark. We should just set the h/w controls to 50% and then avoid any further work in software. It's far more efficient and better for battery life etc. Of course we still maintain the outward perception that the h/w is at 90%. Thus if you do fiddle and play with the underlying controls, you may see odd results and things changing when you do not expect it. However, if you must, just run: "alsamixer -c0" or "KMIX_PULSEAUDIO_DISABLE=1 kmix". As for this problem, please keep in mind that this is nothing to do with PulseAudio specifically. It's purely an osspd issue. I would actually prefer to use it on both ALSA and PulseAudio profiles for OSS support and I will be pushing for that in Mga3. It should be able to push sound to alsa rather than PA in that mode and it would do away with all the "soundwrapper" hacks that we've previously had to add to lots of apps to make them work with OSS which, without such hacks, will only allow one application to use the sound device, preventing other apps from using it (e.g. your voip app cannot ring to let you know someone is calling). Of course soundwrapper can also cause problems with some apps, so it's not a magic fix. The next version of osspd with appropriate kernel changes should allow full mmap support which should be the final missing link to it being usable by all apps, including games and such that need this. Finally something that should work everywhere. So handling OSS audio is a royal pain, but please do not attach it to PulseAudio specifically. It's a pain on it's own without any further complications! @David: Please post the output of "systemctl status osspd.service" On my system: osspd.service - OSS (Open Sound System) Proxy Daemon Loaded: loaded (/lib/systemd/system/osspd.service; enabled) Active: active (running) since Sun, 03 Jun 2012 16:36:31 +0100; 4h 42min ago Main PID: 1471 (osspd) CGroup: name=systemd:/system/osspd.service â 1471 /usr/sbin/osspd If you do not have a /dev/dsp or /dev/mixer, please try restarting the service (systemctl restart osspd.service) and failing that magically working, please post the output of "lsmod | grep -E 'snd|oss'"
(In reply to comment #29) > In my case, with pavucontrol, I am seeing the output as "Dummy Output". What I > WANT to see is output to the specific audio device. - George This is generally indicative of a permissions problem or some other (alsa or OSS) app hogging the device when PulseAudio starts. If this happens on a fresh boot, please open a new bug and I'll help you debug the issue there.
Ok , So I installed the package "ossp-1.3.2-3.mga2.x86_64.rpm" which was missing on my Mageia 2. Then I have reboot the PC to start osspd daemon. And now I can confirm that the device /dev/mixer is created ,I can also set aMSN correctly too ,the sound works properly and aMSN too. -------------------------------------------------------------- # ps -afe | egrep osspd root 753 1 0 22:02 ? 00:00:00 /usr/sbin/osspd root 2893 2842 0 22:04 pts/1 00:00:00 egrep --color osspd ------------------------------------------------------------ # ps -afe | egrep pulse david 2287 1 0 22:03 ? 00:00:00 /usr/bin/pulseaudio --start --log-target=syslog david 2299 2287 0 22:03 ? 00:00:00 /usr/lib64/pulse/gconf-helper root 2912 2842 0 22:04 pts/1 00:00:00 egrep --color pulse ------------------------------------------------------------- $ amsn ioctl: VIDIOC_S_CTRL(id=9963776;value=96): Invalid argument ioctl: VIDIOC_S_CTRL(id=9963777;value=2): Invalid argument ioctl: VIDIOC_S_CTRL(id=9963779;value=2): Invalid argument ioctl: VIDIOC_S_CTRL(id=9963778;value=6): Invalid argument ioctl: VIDIOC_S_CTRL(id=9963776;value=96): Invalid argument ioctl: VIDIOC_S_CTRL(id=9963777;value=2): Invalid argument ioctl: VIDIOC_S_CTRL(id=9963779;value=2): Invalid argument ioctl: VIDIOC_S_CTRL(id=9963778;value=6): Invalid argument ioctl: VIDIOC_S_CTRL(id=9963776;value=96): Invalid argument ioctl: VIDIOC_S_CTRL(id=9963777;value=2): Invalid argument ioctl: VIDIOC_S_CTRL(id=9963779;value=2): Invalid argument ioctl: VIDIOC_S_CTRL(id=9963778;value=6): Invalid argument ----------------------------------------------------------------- Thank you George Mitchell for your good help. What can we conclude?
$ systemctl status osspd.service osspd.service - OSS (Open Sound System) Proxy Daemon Loaded: loaded (/lib/systemd/system/osspd.service; disabled) Active: active (running) since Sun, 03 Jun 2012 22:02:44 +0200; 22min ago Process: 751 ExecStart=/usr/sbin/osspd (code=exited, status=0/SUCCESS) Main PID: 753 (osspd) CGroup: name=systemd:/system/osspd.service â 753 /usr/sbin/osspd -------------------------------------------------------------- # lsmod | grep -E 'snd|oss' snd_hda_codec_realtek 145436 1 snd_hda_intel 33293 3 snd_hda_codec 126641 2 snd_hda_intel,snd_hda_codec_realtek snd_hwdep 17659 1 snd_hda_codec snd_pcm 100893 2 snd_hda_codec,snd_hda_intel snd_page_alloc 18484 2 snd_pcm,snd_hda_intel snd_timer 29532 1 snd_pcm snd 82622 12 snd_timer,snd_pcm,snd_hwdep,snd_hda_codec,snd_hda_intel,snd_hda_codec_realtek soundcore 15047 1 snd
Thanks for the output but actually your previous reply was sufficient in the end. It seems the default install didn't include osspd, which I guess is fair enough as it's not often used. I'll try and improve packaging for the next release.
Colin, Thank you VERY much for your kind response after my angry attack on your life's work. I will continue to work on this as I have the time. For the most part I REALLY DO like pulse audio and I REALLY DO sincerely appreciate all of the work that you and the rest of the pa team have put into it. What I am looking for and not finding though are things like separate controls for for headphone and speaker, microphone and line in. Those sorts of things. I don't know how many times in the past I have come up with everything looking fine, but with some input or output not working, only to put up the full scope of discreet inputs and outputs and finding one of the sub categories somehow had become muted. And when you don't have the tools to see ALL of these subcategories, it is REALLY frustrating. So there REALLY, REALLY, needs to be a very visible "Expert Mode" key to sound configuration that exposes ALL of the possible configuration points. And the Default Mode, on the other hand, needs a simple "Revert to Default" key to fix things when the novice screws them up. But thanks again for the tips. - George
(In reply to comment #34) > Thanks for the output but actually your previous reply was sufficient in the > end. It seems the default install didn't include osspd, which I guess is fair > enough as it's not often used. > > I'll try and improve packaging for the next release. Yes when I installed aMSN, the proposed to install "ossp" was not included : # urpmi amsn Pour satisfaire les dépendances, les paquetages suivants vont être installés : Paquetage Version Révision Arch (média « Core Release (distrib1) ») amsn 0.98.4 9.mga2 x86_64 libnice-utils 0.1.1 5.mga2 x86_64 tcl-snack 2.2.10 10.mga2 x86_64 tcltls 1.6 4.mga2 x86_64 un espace additionnel de 24Mo sera utilisé. 11Mo de paquets seront récupérés. Procéder à l'installation des 4 paquetages ? (O/n) O
Colin, Actually I just solved a problem that I have been trying to figure out for weeks. I am routing sound to two different sets of speakers, one set via the speaker jack and the other set via the headphone jack on our system. This has always worked flawlessly. As soon as ossp came into play that all failed. Suddenly when you plug into the headphone jack, the speaker jack is muted and what we had been doing for ages was no longer possible and NOTHING was available via sound controls provided to fix it. Now by killing ossp and going back to ALSA, suddenly one of the many options to pop up is "Auto Mute Mode" control. And presto, when I disable Auto Mute, everything works as it did before and my sound is back on both speaker systems. THIS is the kind of control I need available for these sorts of issues which seem to pop up on a routine basis. - George
Well, well, well. Colin, my sincerest apologies and my deepest gratitude for your encouragement on this. At this point, I have ripped out ossp and re-installed it and re-booted and ossp now DOES create /dev/mixer AND everything, including the OSS utilities are now working normally. I can even access ALL of the native options now with the ALSA utilities. So, apparently something went wrong in the upgrade itself that resulted in the sound problems I was experiencing. So my problem is solved as well as, apparently, David's problem and unless something pops up later, which I don't expect, this particular ticket can probably be closed and ossp in particular and pulse audio in general have been vindicated. But I WOULD appreciate it if you will consider moving the ossp compat stuff out of sound-scripts and into ossp, just for the sake of good practice on the packaging side. Thanks, George
For me ,I consider that this bug is resolved. The srpm package amsn-0.98.9-0.1.mga2.src.rpm, it may be pushed from Core_Updates_Testing to Core_Updates? Thank you in advance.
For helping the QA >> https://bugs.mageia.org/show_bug.cgi?id=6272#c4
Depends on: (none) => 6272
Linking done and update pushed: https://wiki.mageia.org/en/Support/Advisories/MGAA-2012-0087
Status: NEW => RESOLVEDCC: (none) => tmbResolution: (none) => FIXED