+++ This bug was initially created as a clone of Bug #497053 +++ Description of problem: gnome-volume-control doesn't provide any chance of changing device. I don't want to use pulseaudio and want to use alsa, but gnome-volume-control doesn't allow it. Previously it was possible. Version-Release number of selected component (if applicable): gnome-media-2.26.0-2.fc11.i586 How reproducible: Steps to Reproduce: 1. gnome-volume-control 2. Wanna change device? 3. Actual results: No chance Expected results: Just like in fedora 8 possibility to choose device. Additional info: Isn't it regression? --- Additional comment from bnocera on 2009-04-22 04:38:33 EDT --- Changing what device to do what? --- Additional comment from rrakus on 2009-04-22 04:49:49 EDT --- ah, sry In F-8 you have in menu File -> Change Device -> and you can choose from a list alsa, OSS, PulseAudio... --- Additional comment from bnocera on 2009-04-22 05:58:05 EDT --- The output devices and input devices show up under their own tabs. We use PulseAudio, we don't show the underlying ALSA devices, and certainly not OSS devices. --- Additional comment from rrakus on 2009-04-22 06:24:31 EDT --- And why not show ALSA devices? Now is only two choices: Delayed sound with PulseAudio or not any sound. People who want normal playing sounds should go to another desktop? --- Additional comment from bnocera on 2009-04-22 06:47:58 EDT --- Then file a bug against PulseAudio please. The volume control uses PulseAudio, it doesn't use ALSA. And working around the problem by showing ALSA devices doesn't actually help us at all.
What exactly is this bug about? This bug does not describe any bug in PA, or am I blind? If you are asking me that we should wrap more ALSA mixer controls, then no, this is not going to happen.
No, it's about that: "Now is only two choices: Delayed sound with PulseAudio or not any sound." Obviously a log from pulseaudio is required.
Ok, Roman, please enlighten me about what you mean by "delayed" sound.
OK, some examples: In terminal pressing tab -> beep sound, but after a second. Playing any audio -> Scratchy pauses after few seconds. If I set audio players (mplayer, vlc) to use ALSA, everything is OK, but media keys (volume up, volume down, mute...) aren't working.
(In reply to comment #4) > OK, some examples: > In terminal pressing tab -> beep sound, but after a second. > Playing any audio -> Scratchy pauses after few seconds. Please provide an output of pulseaudio -vvvvv when this happens. Run it in a terminal. You might need to run "pulseaudio -k" first. Please tell me which application you are using to play 'any audio'? Is this F11 or F10? Regarding that beep sound delay: if you run pulseaudio -vvvv as suggested, is there instant reaction to your pressing of tab in the output, or is that delayed already? > If I set audio players (mplayer, vlc) to use ALSA, everything is OK, but media > keys (volume up, volume down, mute...) aren't working. This has nothing to do with PA.
Created attachment 341357 [details] Output from pulseaudio -vvvvv Here is log. What I done: 1) Run 'pulseaudio -k' 2) Run 'pulseaudio -vvvv' 3) Run vlc player, set audio output from ALSA to pulseaudio 4) Restart vlc At start sound was scratchy (syncing?). After few seconds it was OK, but from time to time there was some scrathes... I can't reproduce delayed beep sound now :( After the start of gnome, there isn't any beep sound. I just can only see in sound applet that sound is muted when I press tab (but not any sound). When I run steps 1 and 2, there is pc speeker beeping. And from `top': 3209 rrakus 20 0 162m 5500 4212 S 7.6 0.5 0:10.65 pulseaudio 7.6% of CPU time is too much, I think...
And its rawhide: [rrakus@localhost ~]$ rpm -q pulseaudio vlc pulseaudio-0.9.15-11.fc11.i586 vlc-1.0.0-0.2pre1.fc11.i586
Make subject match bug contents a bit more.
Hmm, for some unknown reason VLC asks PA for 225ms, and then fails to hand us the data quickly enough. There is no reason for VLC to request that relatively low latency, especially if it cannot fulfil our data requests then. This needs be fixed in VLC. I have added this to my todo list now. Can you get me any more information about the other issues you reported?
I can't reproduce delayed sound now. High CPU usage is by design, isn't it?
(In reply to comment #10) > High CPU usage is by design, isn't it? Yes, of course. I always design my software in ways that I can eat as much as CPU as possible. But seriously, of course it's not by design. PA adjusts its wakeup rate depending on the latency needs of its clients. Shorter latencies means higher CPU load. Now VLC asks for relatively short latencies as pointed out which hence drives PA's CPU usage up. If PA needs to do resampling this might eat a bit of CPU too. A well behaving client which has no latency requirements (i.e. a media player) would allow PA to go down to 1 wakeup per second. Which is much better for the CPU usage and power consumption than with the old classic playback models.
>Yes, of course. I always design my software in ways that I can eat as much as >CPU as possible. So there is a long way awaiting you to reach Valhalla :) Thanks for explanation. Closing this bug. When I will be able to reproduce delayed beep sound again, I will reopen this.