Re: [pulseaudio-discuss] pulseaudio-0.9.21, alsa-1.0.23, kde-4.4.5, consolekit, dbus
On 09/12/10 19:04, sibu xolo wrote:
pcm.pulse {
type pulse
}
ctl.pulse {
type pulse
}
pcm.!default {
type pulse
}
ctl.!default {
type pulse
}
Try the following, it should allow alsamixer to control the default device
pcm.pulse {
type pulse
}
ctl.pulse {
type pulse
}
#pcm.!default {
#type pulse
#}
#ctl.!default {
#type pulse
#}
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] echocnzelation and feedback killer
On Sat, 2010-09-11 at 17:49 +0200, Alexey Fisher wrote: Hallo all, i see in git you working on echo cancelation. Will it work for audio feedback/Larsen effect too? I mean sort of feedback killer? It will not. The echo cancellation module is meant for things like voip calls. For example, if you're using speakers and a mic, whatever the other end says goes back through the mic, and they will be hear themselves after a short gap. That's the echo we're trying to cancel. So the goal is for the *far end* to not hear echo. It will not make a difference locally. Cheers, Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] echocnzelation and feedback killer
Am Montag, den 13.09.2010, 12:22 +0530 schrieb Arun Raghavan: On Sat, 2010-09-11 at 17:49 +0200, Alexey Fisher wrote: Hallo all, i see in git you working on echo cancelation. Will it work for audio feedback/Larsen effect too? I mean sort of feedback killer? It will not. The echo cancellation module is meant for things like voip calls. For example, if you're using speakers and a mic, whatever the other end says goes back through the mic, and they will be hear themselves after a short gap. That's the echo we're trying to cancel. So the goal is for the *far end* to not hear echo. It will not make a difference locally. Audio feedback is exactly problem of VOIP. Mic monitor is turned off by default, locally y'll not get it . If you use empathy (not skype) for audio chat, without headset (on both sites) you will get high-pitched squealing noise. Skype kill it normally by autosetting the record level. But i think you probably answered on my question. Theoretically it should cancel it too, i need just test it :D ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] echocnzelation and feedback killer
On 2010-9-13 14:52, Arun Raghavan wrote: On Sat, 2010-09-11 at 17:49 +0200, Alexey Fisher wrote: Hallo all, i see in git you working on echo cancelation. Will it work for audio feedback/"Larsen effect" too? I mean sort of feedback killer? It will not. The echo cancellation module is meant for things like voip calls. For example, if you're using speakers and a mic, whatever the other end says goes back through the mic, and they will be hear themselves after a short gap. That's the echo we're trying to cancel. So the goal is for the *far end* to not hear echo. It will not make a difference locally. Cheers, Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] pulseaudio-0.9.21, alsa-1.0.23, kde-4.4.5, consolekit, dbus
'Twas brillig, and sibu xolo at 13/09/10 02:04 did gyre and gimble: a) I am using system5 init and alsamixer refuses to start on the CLI at run- level 3 reporting pulseaaudio' connection refused (or somesuch) but... I guess PA cannot start on the CLI for some reason. alsamixer or aplay should autospawn PA if it's not running (which would be typical with a console login). I suspect not being able to connect to dbus/consolekit is the problem, but to find out, run pulseaudio -vvv from the cli rather than aplay and it should tell you the reasons for not starting. b) alsamixer starts after login in kde in konsole; sound devices are correctly reported (on the cli); aplay reports no errors but no sound is heard and outputs are not mute. Check the profiles in pavucontrol's configuration tab. Post the output from pacmd ls to allow others to have a look at the setup. b) Still in kde, When the ownership/permissions on /usr/lib/dbus-1.0/dbus- daemon-launch-helper file are set as shown above the KDE System Settings/Multimedia dialog reports a dummy device $ ll /lib64/dbus-1/dbus-daemon-launch-helper -rwsr-x--- 1 root messagebus 47384 2010-03-24 09:46 /lib64/dbus-1/dbus-daemon-launch-helper Same perms here... I'm not sure why dbus failure would results in a dummy device. I wonder if it's simply that PA cannot reserve the audio device via the dbus based device reservation protocol and thus can't load the sink. Even still dbus based activation seems to work for me :s Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] pulseaudio-0.9.21, alsa-1.0.23, kde-4.4.5, consolekit, dbus
On Monday 13 September 2010 09:28:22 Colin Guthrie wrote: 'Twas brillig, and sibu xolo at 13/09/10 02:04 did gyre and gimble: a) I am using system5 init and alsamixer refuses to start on the CLI at run- level 3 reporting pulseaaudio' connection refused (or somesuch) but... I guess PA cannot start on the CLI for some reason. alsamixer or aplay should autospawn PA if it's not running (which would be typical with a console login). I suspect not being able to connect to dbus/consolekit is the problem, but to find out, run pulseaudio -vvv from the cli rather than aplay and it should tell you the reasons for not starting. here is the ooutput from running pulseaudio -vvv on the cli BEFORE kde starts I: main.c: setrlimit(RLIMIT_NICE, (31, 31)) failed: Operation not permitted I: main.c: setrlimit(RLIMIT_RTPRIO, (9, 9)) failed: Operation not permitted D: core-rtclock.c: Timer slack is set to 50 us. I: core-util.c: Failed to acquire high-priority scheduling: No such file or directory I: main.c: This is PulseAudio 0.9.21 D: main.c: Compilation host: x86_64-unknown-linux-gnu D: main.c: Compilation CFLAGS: -g -O2 -Wall -W -Wextra -pipe -Wno-long-long - Winline -Wvla -Wno-overlength-strings -Wunsafe-loop-optimizations -Wundef - Wformat=2 -Wlogical-op -Wsign-compare -Wformat-security -Wmissing-include-dirs -Wformat-nonliteral -Wold-style-definition -Wpointer-arith -Winit-self - Wdeclaration-after-statement -Wfloat-equal -Wmissing-prototypes -Wstrict- prototypes -Wredundant-decls -Wmissing-declarations -Wmissing-noreturn - Wshadow -Wendif-labels -Wcast-align -Wstrict-aliasing=2 -Wwrite-strings -Wno- unused-parameter -ffast-math -Wp,-D_FORTIFY_SOURCE=2 -fno-common - fdiagnostics-show-option D: main.c: Running on host: Linux x86_64 2.6.35.4nbf8DRIm #1 SMP PREEMPT Wed Sep 8 15:10:46 BST 2010 D: main.c: Found 2 CPUs. I: main.c: Page size is 4096 bytes D: main.c: Compiled with Valgrind support: yes D: main.c: Running in valgrind mode: no D: main.c: Running in VM: no D: main.c: Optimized build: yes D: main.c: All asserts enabled. I: main.c: Machine ID is 1385ab3a82291ea2800476890006. I: main.c: Using runtime directory /home/sx/.pulse/1385ab3a82291ea2800476890006-runtime. I: main.c: Using state directory /home/sx/.pulse. I: main.c: Using modules directory /opt/lib/pulse-0.9.21/modules. I: main.c: Running in system mode: no I: main.c: Fresh high-resolution timers available! Bon appetit! I: cpu-x86.c: CPU flags: MMX SSE SSE2 SSE3 MMXEXT 3DNOW 3DNOWEXT I: svolume_mmx.c: Initialising MMX optimized functions. I: remap_mmx.c: Initialising MMX optimized remappers. I: svolume_sse.c: Initialising SSE2 optimized functions. I: remap_sse.c: Initialising SSE2 optimized remappers. I: sconv_sse.c: Initialising SSE2 optimized conversions. D: memblock.c: Using shared memory pool with 1024 slots of size 64.0 KiB each, total size is 64.0 MiB, maximum usable slot size is 65472 D: database-gdbm.c: Opened GDBM database '/home/sx/.pulse/1385ab3a82291ea2800476890006-device-volumes.x86_64- unknown-linux-gnu.gdbm' I: module-device-restore.c: Sucessfully opened database file '/home/sx/.pulse/1385ab3a82291ea2800476890006-device-volumes'. I: module.c: Loaded module-device-restore (index: #0; argument: ). D: database-gdbm.c: Opened GDBM database '/home/sx/.pulse/1385ab3a82291ea2800476890006-stream-volumes.x86_64- unknown-linux-gnu.gdbm' I: module-stream-restore.c: Sucessfully opened database file '/home/sx/.pulse/1385ab3a82291ea2800476890006-stream-volumes'. I: module.c: Loaded module-stream-restore (index: #1; argument: ). D: database-gdbm.c: Opened GDBM database '/home/sx/.pulse/1385ab3a82291ea2800476890006-card-database.x86_64- unknown-linux-gnu.gdbm' I: module-card-restore.c: Sucessfully opened database file '/home/sx/.pulse/1385ab3a82291ea2800476890006-card-database'. I: module.c: Loaded module-card-restore (index: #2; argument: ). I: module.c: Loaded module-augment-properties (index: #3; argument: ). D: cli-command.c: Checking for existance of '/opt/lib/pulse-0.9.21/modules/module-udev-detect.so': success I: module-udev-detect.c: Found 0 cards. I: module.c: Loaded module-udev-detect (index: #4; argument: ). D: cli-command.c: Checking for existance of '/opt/lib/pulse-0.9.21/modules/module-bluetooth-discover.so': success D: dbus-util.c: Successfully connected to D-Bus system bus 244284b9a8358759ce53123d0008 as :1.7 D: bluetooth-util.c: dbus: interface=org.freedesktop.DBus, path=/org/freedesktop/DBus, member=NameAcquired D: bluetooth-util.c: Bluetooth daemon is apparently not available. I: module.c: Loaded module-bluetooth-discover (index: #5; argument: ). D: cli-command.c: Checking for existance of '/opt/lib/pulse-0.9.21/modules/module-esound-protocol-unix.so': success I: module.c: Loaded module-esound-protocol-unix (index: #6; argument: ). I: module.c: Loaded module-native-protocol-unix (index: #7; argument: ). D: cli-command.c: Checking for existance of
Re: [pulseaudio-discuss] [PATCH] Do not use tsched watermark if tsched is disabled
On 2010-09-04 14:10, Colin Guthrie wrote: 'Twas brillig, and David Henningsson at 03/09/10 09:46 did gyre and gimble: 2010-09-02 16:06, pl bossart skrev: Agreed: You can pick those two patches, and then we add a third patch to both branches, which brings back the watermark for tsched devices and 20 ms for non-tsched. Assuming my suspicion is not disproved, of course. What does Pierre think of that? I don't want the watermark to be used for rewinds. The watermark is there for timer-based scheduling, so that you have enough time to wake-up from sleep and still refill the buffer. The rewinds happens when the processor is already awake, pulseaudio up and running and only the remix part needs to happen. Plus the watermark varies and the logic could really be improved. Also I think 20ms for rewinds is way too much. This will kill your actual latency. Imagine you have a low-latency app that starts, the first sample would be heard after at best 20ms. Not acceptable for speech or interactive sounds. But I agree that 256-bytes isn't fool-proof for heavy duty use cases such 8ch 192kHz 32-bit float. So how about we keep 256 bytes (1.33 ms for 48kHz) but add a 1.33 ms threshold to make sure we never rewind below. rewind_safeguard = max(256, pa_usec_to_bytes(1330)); This way you solve both the hardware issue (frequency independent) and leave enough headroom for the system to avoid underflows. Whether 1,33 ms or 20 ms is best - I assume your guess is as good as mine. Colin, feel free to go ahead with Pierre's suggestion - it's likely to be good enough. As for the watermark usage, I admit to not knowing enough of CPU scheduling and wake-up times to either prove Pierre right or wrong. OK, I've done this now. The patch is attached. It's based on stable-queue with the two previous patches cherry-picked first (and also Tanu's 0525807b63c11d3d71526cec553e8d80ad3f09cd which fixed a complier warning, but shouldn't get in the way) However, in testing this I had some problems. Likely this is due to me testing hard/more thoroughly than before. I found that using the attached patch fixed the chordtest.sh case for tsched=0, however, when running pavucontrol at the same time, everything started to go wrong pretty quickly (after two or three streams). When things when wrong, they generally stayed wrong. i.e. ctrl+c on the chordtest.sh kills all the streams, but if I rerun it, then the very first stream is generally cocked up. Interestingly a paplay seemed to work fine. So I changed the 1330 usec to 2 and tried again. This had slightly better results, but still broke the chordtest.sh case after three streams (fairly repeatable) when pavucontrol is running (unsurprisingly it also worked fine when pavucontrol was not running). The difference in this case however was the rerunning the test after an initial failure worked fine. The sound was back to normal on the first stream and only generally cocked up when it hit the third stream. So what does this test mean? pavucontrol obviously affects the latency of the sink due to it's VI meters. This obviously increases the likelihood of a rewind being triggered. So, with this in mind what values do you suggest we pick? I'd be interested as to whether anyone else can repeat this experiment and get similar results. Do you guys get a broken chordtest too (it's on the RedHat bug I mentioned at the beginning of this thread)? I have now tried to repeat the experiment. The chordtest.sh seems to be buggy in itself (the cleanup does not remove the gst-launch, which in turn had to be renamed to gst-launch-0.10 here). Anyway, the results were not encouraging - with tsched=0, pavucontrol, and - to syslog on, three tones were heard, then things went quiet - however, pulseaudio started to eat more and more memory. Quickly my machine started swapping and became unresponsive, so I killed PA. Besides that, when I looked at pavucontrol, only the meters of the first three were moving, the other ones were silent. My log got filled up with memblockq: pool full as well. I'm getting the feeling that this problem is something different, unrelated to DMA controller hardware. My suggestion is that you should commit your proposed patch as it improves the situation compared to the current situation. If there are additional problems, let's nail them down separately. -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] pulseaudio-0.9.21, alsa-1.0.23, kde-4.4.5, consolekit, dbus
'Twas brillig, and sibu xolo at 13/09/10 11:10 did gyre and gimble: On Monday 13 September 2010 09:28:22 Colin Guthrie wrote: 'Twas brillig, and sibu xolo at 13/09/10 02:04 did gyre and gimble: a) I am using system5 init and alsamixer refuses to start on the CLI at run- level 3 reporting pulseaaudio' connection refused (or somesuch) but... I guess PA cannot start on the CLI for some reason. alsamixer or aplay should autospawn PA if it's not running (which would be typical with a console login). I suspect not being able to connect to dbus/consolekit is the problem, but to find out, run pulseaudio -vvv from the cli rather than aplay and it should tell you the reasons for not starting. here is the ooutput from running pulseaudio -vvv on the cli BEFORE kde starts OK, you've got two problems here: D: cli-command.c: Checking for existance of '/opt/lib/pulse-0.9.21/modules/module-udev-detect.so': success I: module-udev-detect.c: Found 0 cards. I: module.c: Loaded module-udev-detect (index: #4; argument: ). For whatever reason, udev detection has failed and is finding no cards. This means an Auto Null sink will be loaded rather than accessing your real h/w. E: x11wrap.c: XOpenDisplay() failed E: module.c: Failed to load module module-x11-bell (argument: sample=bell- windowing-system): initialization failed. E: main.c: Module load failed. E: main.c: Failed to initialize daemon. This is interesting. The directive for loading module-x11-bell was removed from default.pa a *long* time ago, but apparently your default.pa is still trying to load it. But as your default.pa tries to load module-udev-detect, which was added *after* module-x11-bell was removed, it suggests you have edited the default.pa we ship with your own version. If you want the x11-bell module to be loaded, you should really add it to the /usr/bin/start-pulseaudio-x11 script instead. You can also put the load-module line in default.pa inside a .nofail .fail block. This will mean it will not cause daemon startup to fail, but it obviously will not actually load the module when X11 login actually occurs. That's why putting it in start-pulseaudio-x11 is better. here is the ooutput from running pacmd ls on the cli AFTER kde starts 1 sink(s) available. * index: 0 name: auto_null driver: module-null-sink.c flags: DECIBEL_VOLUME LATENCY FLAT_VOLUME DYNAMIC_LATENCY state: SUSPENDED suspend cause: IDLE priority: 1000 volume: 0: 60% 1: 60% 0: -13.31 dB 1: -13.31 dB balance 0.00 base volume: 100% 0.00 dB volume steps: 65537 muted: no current latency: 0.00 ms max request: 1722 KiB max rewind: 1722 KiB monitor source: 0 sample spec: s16le 2ch 44100Hz channel map: front-left,front-right Stereo used by: 0 linked by: 0 configured latency: 0.00 ms; range is 0.50 .. 1.00 ms module: 10 properties: device.description = Dummy Output device.class = abstract device.icon_name = audio-card Here is the ultimately issue. The Dummy Output. As udev-detect could not detect any cards, you get only the dummy output. I'm not sure why udev-detect would cause problems. I would suggest to double check your udev setup and make sure the relevant udev rules are present on your system. udev 147 is pretty old, perhaps a newer version is needed (I can't remember the minimum system requirements), but certainly: /lib/udev/rules.d/78-sound-card.rules Should be present and should control things in this regard. I'd certainly double check that ACLs are written properly on the /dev/snd/* nodes (getfacl /dev/snd/*) and that your user session is definitely listed in ck-list-sessions as being active. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] Do not use tsched watermark if tsched is disabled
'Twas brillig, and David Henningsson at 13/09/10 11:14 did gyre and gimble: On 2010-09-04 14:10, Colin Guthrie wrote: 'Twas brillig, and David Henningsson at 03/09/10 09:46 did gyre and gimble: 2010-09-02 16:06, pl bossart skrev: Agreed: You can pick those two patches, and then we add a third patch to both branches, which brings back the watermark for tsched devices and 20 ms for non-tsched. Assuming my suspicion is not disproved, of course. What does Pierre think of that? I don't want the watermark to be used for rewinds. The watermark is there for timer-based scheduling, so that you have enough time to wake-up from sleep and still refill the buffer. The rewinds happens when the processor is already awake, pulseaudio up and running and only the remix part needs to happen. Plus the watermark varies and the logic could really be improved. Also I think 20ms for rewinds is way too much. This will kill your actual latency. Imagine you have a low-latency app that starts, the first sample would be heard after at best 20ms. Not acceptable for speech or interactive sounds. But I agree that 256-bytes isn't fool-proof for heavy duty use cases such 8ch 192kHz 32-bit float. So how about we keep 256 bytes (1.33 ms for 48kHz) but add a 1.33 ms threshold to make sure we never rewind below. rewind_safeguard = max(256, pa_usec_to_bytes(1330)); This way you solve both the hardware issue (frequency independent) and leave enough headroom for the system to avoid underflows. Whether 1,33 ms or 20 ms is best - I assume your guess is as good as mine. Colin, feel free to go ahead with Pierre's suggestion - it's likely to be good enough. As for the watermark usage, I admit to not knowing enough of CPU scheduling and wake-up times to either prove Pierre right or wrong. OK, I've done this now. The patch is attached. It's based on stable-queue with the two previous patches cherry-picked first (and also Tanu's 0525807b63c11d3d71526cec553e8d80ad3f09cd which fixed a complier warning, but shouldn't get in the way) However, in testing this I had some problems. Likely this is due to me testing hard/more thoroughly than before. I found that using the attached patch fixed the chordtest.sh case for tsched=0, however, when running pavucontrol at the same time, everything started to go wrong pretty quickly (after two or three streams). When things when wrong, they generally stayed wrong. i.e. ctrl+c on the chordtest.sh kills all the streams, but if I rerun it, then the very first stream is generally cocked up. Interestingly a paplay seemed to work fine. So I changed the 1330 usec to 2 and tried again. This had slightly better results, but still broke the chordtest.sh case after three streams (fairly repeatable) when pavucontrol is running (unsurprisingly it also worked fine when pavucontrol was not running). The difference in this case however was the rerunning the test after an initial failure worked fine. The sound was back to normal on the first stream and only generally cocked up when it hit the third stream. So what does this test mean? pavucontrol obviously affects the latency of the sink due to it's VI meters. This obviously increases the likelihood of a rewind being triggered. So, with this in mind what values do you suggest we pick? I'd be interested as to whether anyone else can repeat this experiment and get similar results. Do you guys get a broken chordtest too (it's on the RedHat bug I mentioned at the beginning of this thread)? I have now tried to repeat the experiment. The chordtest.sh seems to be buggy in itself (the cleanup does not remove the gst-launch, which in turn had to be renamed to gst-launch-0.10 here). Yeah I have gst-launch-0.10 here too... not quite sure why, I'd have thought we could ditch the old 0.8 support by now but hey ho. (I don't follow gst dev super closely) I thought that the script trapped ctrl+c and killed any processes started. It seems to be clean for me. Perhaps the problem is that /bin/sh is not actually bash on your system? Perhaps just changing the first line to: #!/bin/bash would cause it to tidy things up properly? Anyway, the results were not encouraging - with tsched=0, pavucontrol, and - to syslog on, three tones were heard, then things went quiet - however, pulseaudio started to eat more and more memory. Quickly my machine started swapping and became unresponsive, so I killed PA. Besides that, when I looked at pavucontrol, only the meters of the first three were moving, the other ones were silent. My log got filled up with memblockq: pool full as well. I'm getting the feeling that this problem is something different, unrelated to DMA controller hardware. Interesting, can't say I noticed this, but I probably wasn't looking closely enough. My suggestion is that you should commit your proposed patch as it improves the situation compared to the current situation. If there are additional
