[pulseaudio-discuss] [PATCH] Re: Why is it still hissing?
On 2011-05-25 14:41, Andrew Lutomirski wrote: On Tue, May 24, 2011 at 10:04 AM, David Henningsson david.hennings...@canonical.com wrote: Ok, so there is still a high-pitched noise with 5.1, although I tried to fix that a while ago. I now know what the error is, but perhaps somewhat with more GCC-ASM skills can help me fix it. I spent parts of yesterday and today analysing it and came up with the following conclusion: Here's the asm code as written in svolume_sse.c, function pa_volume_s16ne_sse2: #define MOD_ADD(a,b) \ add #a, %3 \n\t /* channel += inc */ \ mov %3, %4 \n\t\ sub #b, %4 \n\t /* tmp = channel - channels */ \ cmovae %4, %3 \n\t /* if (tmp= 0) channel = tmp */ And called with: MOD_ADD($8, %5) Here's what it shows up with gdb (on i386) : 0x00f3fbe6+550: add$0x8,%edi 0x00f3fbe9+553: mov%edi,%ecx 0x00f3fbeb+555: sub%edi,%ecx 0x00f3fbed+557: cmovae %ecx,%edi The error: both %3 and %5 is turned into the %edi register. Here's the register allocation: : +r (samples), +r (volumes), +r (length), =D (channel), =r (temp) : rm ((pa_reg_x86)channels) : cc As I can tell from the above the =D forces %3 to go into %edi, but I don't know how to tell GCC not to use %edi for %5 (channels) as well, does anybody know? Can this be a GCC bug? Either use +D for channel or rm for channels. The manual here: http://gcc.gnu.org/onlinedocs/gcc/Modifiers.html#Modifiers is pretty good. Thanks! Maybe I've found it if I had googled it better. Unfortunately that didn't work, but after several attempts I came up with something that seems to work here. The problem seems to be with the rm thing itself. Colin (or someone else), if you have time, would you give this a test spin and apply if it works for you? -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic From 75d0e5f5ad7764eba560810c958c5dfa4a248f81 Mon Sep 17 00:00:00 2001 From: David Henningsson david.hennings...@canonical.com Date: Fri, 27 May 2011 09:28:57 +0200 Subject: [PATCH] SSE/MMX: Fix problem with highpitched noise on i386 The rm basm constraint doesn't work with my version of gcc (4.5.2), not even in a simple example. Since we usually only have 5 registers available on i386, force it to be memory on that architecture. Signed-off-by: David Henningsson david.hennings...@canonical.com --- src/pulsecore/svolume_mmx.c | 12 ++-- src/pulsecore/svolume_sse.c | 12 ++-- 2 files changed, 20 insertions(+), 4 deletions(-) diff --git a/src/pulsecore/svolume_mmx.c b/src/pulsecore/svolume_mmx.c index a71a39b..129d7f0 100644 --- a/src/pulsecore/svolume_mmx.c +++ b/src/pulsecore/svolume_mmx.c @@ -155,7 +155,11 @@ pa_volume_s16ne_mmx (int16_t *samples, int32_t *volumes, unsigned channels, unsi emms \n\t : +r (samples), +r (volumes), +r (length), =D ((pa_reg_x86)channel), =r (temp) -: rm ((pa_reg_x86)channels) +#if defined (__i386__) +: m ((pa_reg_x86)channels) +#else +: r ((pa_reg_x86)channels) +#endif : cc ); } @@ -232,7 +236,11 @@ pa_volume_s16re_mmx (int16_t *samples, int32_t *volumes, unsigned channels, unsi emms \n\t : +r (samples), +r (volumes), +r (length), =D ((pa_reg_x86)channel), =r (temp) -: rm ((pa_reg_x86)channels) +#if defined (__i386__) +: m ((pa_reg_x86)channels) +#else +: r ((pa_reg_x86)channels) +#endif : cc ); } diff --git a/src/pulsecore/svolume_sse.c b/src/pulsecore/svolume_sse.c index 5983164..ccf45e7 100644 --- a/src/pulsecore/svolume_sse.c +++ b/src/pulsecore/svolume_sse.c @@ -154,7 +154,11 @@ pa_volume_s16ne_sse2 (int16_t *samples, int32_t *volumes, unsigned channels, uns 8: \n\t : +r (samples), +r (volumes), +r (length), =D (channel), =r (temp) -: rm ((pa_reg_x86)channels) +#if defined (__i386__) +: m ((pa_reg_x86)channels) +#else +: r ((pa_reg_x86)channels) +#endif : cc ); } @@ -244,7 +248,11 @@ pa_volume_s16re_sse2 (int16_t *samples, int32_t *volumes, unsigned channels, uns 8: \n\t : +r (samples), +r (volumes), +r (length), =D (channel), =r (temp) -: rm ((pa_reg_x86)channels) +#if defined (__i386__) +: m ((pa_reg_x86)channels) +#else +: r ((pa_reg_x86)channels) +#endif : cc ); } -- 1.7.4.1 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 1/2] alsa: add jack detection support
I was asked by Colin to give this a quick review, so...
On 2011-05-19 18:44, Jorge Eduardo Candelaria wrote:
From: Margarita Olaya Cabreram...@slimlogic.co.uk
This patch adds support to module-alsa-card so that we can read jack insertion
and removal events using the input device subsystem. i.e. we can detect
headphone insertions and removals.
This patch adds a new module parameter called jack_id that contains the ID of
the jack input device associated with this sound card. If we receive a valid
jack_id during module init then we start a reader thread that will read the
jack input device and fire a hook on every removal and insertion event.
Jack support development was kindly sponsored by Wolfson Microelectronics PLC
Signed-off-by: Margarita Olaya Cabreram...@slimlogic.co.uk
Signed-off-by: Jorge Eduardo Candelariaj...@slimlogic.co.uk
---
src/modules/alsa/alsa-jack.h| 42
src/modules/alsa/module-alsa-card.c | 120 +++
src/pulsecore/core.h|2 +
3 files changed, 164 insertions(+), 0 deletions(-)
create mode 100644 src/modules/alsa/alsa-jack.h
diff --git a/src/modules/alsa/alsa-jack.h b/src/modules/alsa/alsa-jack.h
new file mode 100644
index 000..4fc67c6
--- /dev/null
+++ b/src/modules/alsa/alsa-jack.h
Along the lines of Tanu, if this is not alsa-specific, let's take this
header and move into pulsecore.
@@ -0,0 +1,42 @@
+#ifndef foopulsejackdetecthfoo
+#define foopulsejackdetecthfoo
+
+/***
+ This file is part of PulseAudio.
+
+ Copyright 2011 Wolfson Microelectronics PLC
+ Author Margarita Olayam...@slimlogic.co.uk
+
+ PulseAudio is free software; you can redistribute it and/or modify
+ it under the terms of the GNU Lesser General Public License as published
+ by the Free Software Foundation; either version 2.1 of the License,
+ or (at your option) any later version.
+
+ PulseAudio is distributed in the hope that it will be useful, but
+ WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ General Public License for more details.
+
+ You should have received a copy of the GNU Lesser General Public License
+ along with PulseAudio; if not, write to the Free Software
+ Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
+ USA.
+***/
+
+#includeinttypes.h
+
+typedef enum pa_jack_event {
+PA_JACK_HEADPHONES,
+PA_JACK_HEADSET,
I'm a little hesitant to whether we should have one headset or whether
that should be emulated by one headphone and one microphone, as that
is what a headset is.
+PA_JACK_MICROPHONE,
+PA_JACK_LINEOUT,
add PA_JACK_VIDEOOUT for HDMI/Displayport (which was just added to ALSA).
+PA_JACK_UNKNOWN,
+PA_JACK_MAX
+} pa_jack_event_t;
+
+typedef struct pa_jack_detect {
+pa_jack_event_t event;
+char *card;
Agree with Tanu about pa_card pointer here.
+} pa_jack_detect_t;
+
+#endif
diff --git a/src/modules/alsa/module-alsa-card.c
b/src/modules/alsa/module-alsa-card.c
index e60aa5e..75202fb 100644
--- a/src/modules/alsa/module-alsa-card.c
+++ b/src/modules/alsa/module-alsa-card.c
@@ -29,6 +29,9 @@
#includepulsecore/core-util.h
#includepulsecore/modargs.h
#includepulsecore/queue.h
+#includepulsecore/thread.h
+
+#includelinux/input.h
#includemodules/reserve-wrap.h
@@ -39,6 +42,7 @@
#include alsa-util.h
#include alsa-sink.h
#include alsa-source.h
+#include alsa-jack.h
#include module-alsa-card-symdef.h
PA_MODULE_AUTHOR(Lennart Poettering);
@@ -55,6 +59,7 @@ PA_MODULE_USAGE(
source_properties=properties for the source
namereg_fail=pa_namereg_register() fail parameter value
device_id=ALSA card index
+jack_id=Jack device index
Eh, a card can have more than one jack, and is further rather connected
to a port rather than a card, so this (and thus the rest of the
implementation) doesn't seem right to me.
--
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
[pulseaudio-discuss] Why is it still hissing?
Ok, so there is still a high-pitched noise with 5.1, although I tried to fix that a while ago. I now know what the error is, but perhaps somewhat with more GCC-ASM skills can help me fix it. I spent parts of yesterday and today analysing it and came up with the following conclusion: Here's the asm code as written in svolume_sse.c, function pa_volume_s16ne_sse2: #define MOD_ADD(a,b) \ add #a, %3 \n\t /* channel += inc */ \ mov %3, %4 \n\t\ sub #b, %4 \n\t /* tmp = channel - channels */ \ cmovae %4, %3 \n\t /* if (tmp = 0) channel = tmp */ And called with: MOD_ADD($8, %5) Here's what it shows up with gdb (on i386) : 0x00f3fbe6 +550: add$0x8,%edi 0x00f3fbe9 +553: mov%edi,%ecx 0x00f3fbeb +555: sub%edi,%ecx 0x00f3fbed +557: cmovae %ecx,%edi The error: both %3 and %5 is turned into the %edi register. Here's the register allocation: : +r (samples), +r (volumes), +r (length), =D (channel), =r (temp) : rm ((pa_reg_x86)channels) : cc As I can tell from the above the =D forces %3 to go into %edi, but I don't know how to tell GCC not to use %edi for %5 (channels) as well, does anybody know? Can this be a GCC bug? (Btw, based on this analysis, I'm guessing that my former fix fixed the problem for amd64, but not i386.) -- 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] Dealing with the ThinkPad hardware mixer
Hi Andrew and thanks for dealing with this issue! I'm sometimes working with certifying Lenovo for Canonical/Ubuntu, so this definitely concerns me. However I know very little about the thinkpad-acpi driver and would like to know more about how it works, and especially the mixer part. On 2011-05-23 19:21, Andrew Lutomirski wrote: Most ThinkPad laptops have an extra mixer that has nothing to do with the HDA audio hardware. The kernel can talk to it through the embedded controller and, if it's muted, then there's no sound even if the normal controls are all set on. Does this concern the internal speaker only, or headphones / line out as well? Or can that differ between models? I'm assuming it doesn't mute e g USB headset or audio out over HDMI. These laptops have three special buttons. The mute button either mutes the mixer or toggles the mute state. The volume up button unmutes the mixer (if muted) and sends KEY_VOLUMEUP. The volume down button unmutes the mixer and sends KEY_VOLUMEDOWN. On very new models, there's a hardware mute light that indicates the status of the hardware mute. The thinkpad-acpi driver currently exposes an ALSA mixer and the alsamixer utility can talk to it. But PulseAudio ignores it completely. What is the kernel supposed to do to get PulseAudio to DTRT? Seen from my perspective, and maybe along the lines of Colin's reply, I think the best would be to try to integrate the hw mute in the HDA card at the kernel level (and thus skip card 29 entirely). On some, but not (I think) all, models, we can disable hardware mixer control and make all of the buttons act like ordinary buttons, but that will cause the light (if present) to malfunction, and I don't know if all models can do this. So as it stands, PulseAudio would have to understand that the mixer is special and watch for ALSA change notifications. So, what can the thinkpad-acpi driver do here? Can it e g control the hardware mute status at all, or can that only be done by pressing the keys? I'm willing to change the thinkpad-acpi driver to make it work better, but I know nothing at all about PulseAudio internals. What should I do? (There's an added complexity. Really old models have mute and volume. I don't own one, so I don't know much about how they work.) As a maybe unrelated issue, many of these thinkpads also have a microphone mute hotkey I was hoping to be able to get to work at some point. Assuming we add a new key to linux/input.h, would it be easy for you to fix that in the thinkpad-acpi driver? I think it currently triggers KEY_UNKNOWN. -- 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] Jack detection
On 2011-05-19 20:53, Tanu Kaskinen wrote: On Tue, 2011-05-17 at 13:44 +0200, David Henningsson wrote: Agree with the port property. About the port vs profile question, I think we might think that backwards from a user's perspective. Conceptually I'd say we select port first (manually or automatic; doesn't matter for this reasoning), then we evaluate what profiles make sense to try. If we're on headphones, only stereo profile makes sense, if we're on line-out, we might want to consider surround profiles. At least I would want it to work that way in the UI. Could you elaborate on having profiles without ports? IIRC Pulseaudio would fail in this case. No, Pulseaudio doesn't fail in the scenario that I'm talking about - the no ports situation is an optimization for the case when there would be only one port to select from. If the profile (or more precisely the mapping associated with that profile) has only one path in the mixer configuration, then the sink or source will not export any ports at all. The reasoning for that is probably that having a single port on a sink would be redundant, because currently the only functionality ports offer is that the user can change between them. However, if the available property is added to ports, then exposing even just one port on a sink will not be redundant. Then keeping that port makes more sense IMHO, compared to adding an available property to profiles. I'm not sure what you are proposing with regards to selecting ports. Did I understand correctly that the user should be presented with all ports of all sinks and sources of a card in one big list? Something in that direction. E g in gnome-volume-control, you would still have an output and an input tab (but the hardware tab could be removed). On the output tab you would have: 1) a list of all ports with available != no (assuming we don't optimise ports away) 2) a list of profiles available for that port (stereo, 5.1, etc) 3) balance controls for that profile 4) a test speakers button (moved from hardware tab) 5) a checkbox select this port automatically when it becomes available Does that make sense? -- 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] Jack detection
On 2011-05-20 10:36, Colin Guthrie wrote: 'Twas brillig, and David Henningsson at 20/05/11 07:23 did gyre and gimble: On 2011-05-19 20:53, Tanu Kaskinen wrote: On Tue, 2011-05-17 at 13:44 +0200, David Henningsson wrote: Agree with the port property. About the port vs profile question, I think we might think that backwards from a user's perspective. Conceptually I'd say we select port first (manually or automatic; doesn't matter for this reasoning), then we evaluate what profiles make sense to try. If we're on headphones, only stereo profile makes sense, if we're on line-out, we might want to consider surround profiles. At least I would want it to work that way in the UI. Could you elaborate on having profiles without ports? IIRC Pulseaudio would fail in this case. No, Pulseaudio doesn't fail in the scenario that I'm talking about - the no ports situation is an optimization for the case when there would be only one port to select from. If the profile (or more precisely the mapping associated with that profile) has only one path in the mixer configuration, then the sink or source will not export any ports at all. The reasoning for that is probably that having a single port on a sink would be redundant, because currently the only functionality ports offer is that the user can change between them. However, if the available property is added to ports, then exposing even just one port on a sink will not be redundant. Then keeping that port makes more sense IMHO, compared to adding an available property to profiles. I agree that keeping the single port makes sense - or perhaps even synthesizing two ports (in an ideal world my laptop which does not have separate alsa mixers for HP vs. Spk) would behave in pretty much exactly the same way as a laptop that does. When the jack is detected, I would want the port to change and thus any other code that stores volumes paired to a device+port would magically work in my scenario as the port would actually change (obviously with two synthesized ports, only one could be available at a time). I'm not sure what you are proposing with regards to selecting ports. Did I understand correctly that the user should be presented with all ports of all sinks and sources of a card in one big list? Something in that direction. E g in gnome-volume-control, you would still have an output and an input tab (but the hardware tab could be removed). On the output tab you would have: 1) a list of all ports with available != no (assuming we don't optimise ports away) 2) a list of profiles available for that port (stereo, 5.1, etc) 3) balance controls for that profile 4) a test speakers button (moved from hardware tab) 5) a checkbox select this port automatically when it becomes available Does that make sense? It's hard to visualise without a GUI mockup, but in principle I'm not against something along these lines. In actual fact how I had imagined it was something like this (and this is a topic I'll be discussing at the Desktop Summit as my talk is on exactly this topic - how to expose configuration to the user): List of Sinks: Internal Audio Analog Stereo Speakers Headphones Internal Audio Digital Stereo USB Speakers Network Tunnel to Foobar Bluetooth Headset In this GUI, the profiles are effectively hidden. For any sinks that are not currently present, they are greyed out. For devices that are not currently present but would be possible by changing a card profile, some form of activate button or option is displayed. If there is only one profile that would activate that sink, then the card is switched to that profile and the list redrawn appropriately. If there are more than one profiles that result in that sink, the question is asked of the user Which hardware configuration would you like to use? and then the subset of profiles are show for the user to pick. This unifies the hardware and output tabs (and obviously this would be similarly exposed for input devices too). With regards to ports, I think it makes sense to list them underneath the device. Obviously only one is active at a time, so this could be a drop down rather than a deeper level list. I guess the primary question for me would be: Should we consider sink+port to be a unique key in device order priority lists? Yes. e.g. if we did, then the above presentation (if we assume it were priority list ordered) wouldn't make sense Instead we'd get: List of Sinks: Internal Audio Analog Stereo (Headphones) USB Speakers Internal Audio Analog Stereo (Speakers) Internal Audio Digital Stereo Network Tunnel to Foobar Bluetooth Headset I would even say port first, other things later, like this: Headphones (Internal) Speakers (USB) Speakers (Internal) SPDIF (Internal) Foobar (Network) Headset (Bluetooth) ...because port is what is the closest to the casual user. Note that Analog Stereo is also skipped in the list above as that is part of the profile, and Audio is skipped
[pulseaudio-discuss] Jack detection (was: Re: [PATCHv3 0/4] Read and store UCM data as proplist)
On 2011-05-12 09:37, Tanu Kaskinen wrote: On Wed, 2011-05-11 at 12:43 +0100, Colin Guthrie wrote: 'Twas brillig, and Jorge Eduardo Candelaria at 10/05/11 21:29 did gyre and gimble: This is the third version of the Pulseaudio and UCM integration. This set of patches cover adding ucm data to proplist, adding a ucm API to get and set data to proplist, and lets module-alsa-card scan ucm data when the card is probed. Another set of patches dealing with jack module detection will be sent separately. Thanks for this. I believe David will be helping review this stuff, but is currently at UDS. WRT the jack detection, I think we all agreed that it needs to be handled more internally in the alsa code rather than separated as a module. I'm not 100% sure of the finer details but I know David had ideas here too. We basically need to match up the jack stuff with the appropriate sink/source device on the system and then develop a way to automatically change sink/source ports accordingly (it may also require that we change the card profile too - e.g. change from a 5.1 profile to a stereo profile when plugging in stereo headphones). I'm not sure how to detect multiple jacks - e.g. if you plug in 3 jacks to do 5.1 output, should 5.1 be handled automatically? FWIW, I'll share some thoughts I've had about jack detection (I have not read the proposed code lately): Ports should have a property called available. (Some profiles don't have any ports, so profiles would also have to have the available status. Another possibility is to change this so that even single-mode profiles would have a port, and I think this would actually be a better idea than adding the available status to profiles.) The possible values would be yes, no and no clue. Without jack detection, the value would always be no clue, because currently we have no clue whether a port is actually connected to anything. Agree with the port property. About the port vs profile question, I think we might think that backwards from a user's perspective. Conceptually I'd say we select port first (manually or automatic; doesn't matter for this reasoning), then we evaluate what profiles make sense to try. If we're on headphones, only stereo profile makes sense, if we're on line-out, we might want to consider surround profiles. At least I would want it to work that way in the UI. Could you elaborate on having profiles without ports? IIRC Pulseaudio would fail in this case. Whatever policy we want for automatically switching ports and profiles should be in a separate module. It would follow the port availability status and do something smart with that information. And that's what we're hoping Colin will write some time in the not too distant future :-) Pulseaudio should have an abstraction for jacks. Jack objects would be created by whatever alsa module is appropriate for that. Maybe module-alsa-card would be the best choice, or maybe not. There exists hardware where physical jacks are shared between multiple alsa cards. Really? Is that some embedded scenario? So maybe module-udev-detect would be a better place than module-alsa-card for creating the jacks, or maybe a new module is needed. The alsa modules would then also have to match the physical jacks to the ports, which may be tricky - some ports require multiple jacks to be connected, and on the other hand multiple ports can share one jack. The matching can probably be done for HDA by parsing the event name (you can see this name in evtest) but we might need manual options for people wanting to set up the match manually. Anyway, the status of the jacks associated with a port would determine the available status of the port. Something to keep in mind is also that one physical jack can have more states than connected and not connected. The 3.5 mm jack in N900, for example, can be used with headphones, headsets, microphones, or it can be connected to a TV. These different accessory types should trigger different ports to be activated. So, either the jack objects in Pulseaudio would need to have more than two possible states, or the physical jacks should be mapped to multiple abstract jacks for each accessory type. I'd probably go with the multiple abstract jacks with simple on/off status. Agreed, one jack object for headphone connection, another jack object for microphone. A headset would typically activate both. The TV might be a third jack object. -- 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] Reverting ade0a6f88464d8aecf83982d400ccfc402341920
On 2011-05-13 18:20, Tanu Kaskinen wrote: On Fri, 2011-05-13 at 17:29 +0200, David Henningsson wrote: In short; if we e g have Mic Boost levels at (0dB, 20dB, 40dB and 60dB) and the user wants 30 dB, better have 20dB in hardware and +10dB in software than 40dB in hardware and -10dB in software, as the latter one is more likely to have digital distortion when the signal passes through the ADC. There is a longer email on this list a while back, explaining more of the philosophy behind, but I can't seem to find it right now. Ok, I think I understand why rounding down makes sense when recording. With playback, however, rounding towards 0 dB is definetely broken. My ability to think clearly happens to be currently a bit weakened, so I have to ask you: what's so magic about 0 dB? Here's how I wrote it a while ago, quoting a thread named Mic Input Volume Controls: We want to maximise quality while avoiding digital distortion, that's basically the problem in a nutshell. We're assuming (sometimes incorrectly; but that's our best guess) that this golden spot will be achieved with all sliders at 0 dB. I think my approach makes sense, unless I'm missing something: If we're aiming for something above 0 dB, let's round down to make sure we avoid distortion, and if we're below 0 dB, let's round up to make sure we get maximum quality. And then we always start with the control that's closest to the physical hardware and work our way in. Rethinking that, I don't think I've ever seen any playback volume control that goes above 0 dB. All HDA's I've seen go up to 0 dB only, whereas for recording there is both above and below 0 dB. Therefore the scenario you state has not crossed my mind. So maybe you're right about always rounding up with playback. If there actually was a say +6 dB switch and you wanted +4 dB, then we should do +6 dB in hw and -2 dB in sw as +4 dB in software would potentially cause digital distortion. Right? With playback rounding should always be done up - would it make sense to round always down with capture? Maybe, if we give up the thought of 0 dB being magic. -- David Henningsson http://launchpad.net/~diwic ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] realtime kernel RLIMIT_RTTIME crashes, rewinds
On 2011-05-04 08:19, Tanu Kaskinen wrote: Sorry for the delayed reply. On Wed, 2011-04-27 at 13:23 +0300, Dan Muresan wrote: I've patched (as in attachment) src/daemon/main.c to set the soft rttime limit lower than the hard limit. This way I was able to get a backtrace in gdb when pulseaudio received SIGXCPU due to excessive real-time CPU usage: #0 0x0012d422 in ?? () #1 0x00475edb in write () at ../sysdeps/unix/syscall-template.S:82 #2 0x00153a55 in pa_fdsem_post (f=0x806e178) at pulsecore/fdsem.c:205 #3 0x0013cb0f in push (l=0x8071bc8, p=0x8, wait_op=false) at pulsecore/asyncq.c:161 #4 0x0013d291 in pa_asyncq_post (l=0x8071bc8, p=0x80736d8) at pulsecore/asyncq.c:203 #5 0x0013c1ee in pa_asyncmsgq_post (a=0x8071a90, object=0xb6a16a08, code=7, userdata=0x0, offset=0, chunk=0xb590, free_cb=0) at pulsecore/asyncmsgq.c:139 #6 0x009811d7 in pstream_memblock_callback (p=0x808cf78, channel=0, offset=0, seek=PA_SEEK_RELATIVE, chunk=0xb590, userdata=0x80b6480) at pulsecore/protocol-native.c:4445 #7 0x001dd20b in ?? () from /usr/lib/libpulsecommon-0.9.22.so #8 0x001c823e in ?? () from /usr/lib/libpulsecommon-0.9.22.so #9 0x0021b5fb in pa_mainloop_dispatch () from /usr/lib/libpulse.so.0 #10 0x0021bb11 in pa_mainloop_iterate () from /usr/lib/libpulse.so.0 #11 0x0021bbd4 in pa_mainloop_run () from /usr/lib/libpulse.so.0 #12 0x08052e85 in main (argc=1, argv=0xb854) at daemon/main.c:974 Can someone point out the likely cause, or is this not enough information? This is pulseaudio 0.9.22 from Ubuntu Natty. I would guess that the excessive cpu use is caused by doing rewinds in rapid succession. That's just a guess, though - the backtrace doesn't really give any clue. There have been issues with rewinds happening in some kind of a loop. David Henningson has been working on this problem and he has made at least a few patches that help with the problem. The patches are in Pulseaudio's git repository at least. Since David works for Canonical, I would expect the fixes to be also in Ubuntu, but I don't know for sure. David, what's the status of the fighting rewinds patches in Ubuntu Natty? Is the problem supposed to be fixed already? My rewind patches are both in Natty and stable-queue, but this bug is something different. IIRC I had a quick look at it, didn't have time to look really deep, so I just responded in the launchpad bug Dan also posted in (see https://bugs.launchpad.net/ubuntu/+source/linux-rt/+bug/367671 ) -- David Henningsson http://launchpad.net/~diwic ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] module: new null-source module
On 2011-04-27 15:18, Colin Guthrie wrote: 'Twas brillig, and Tanu Kaskinen at 27/04/11 12:59 did gyre and gimble: On Wed, 2011-04-27 at 14:50 +0300, Tanu Kaskinen wrote: From: Marc-André Lureaumarcandre.lur...@gmail.com --- src/Makefile.am |6 + src/modules/module-null-source.c | 294 ++ 2 files changed, 300 insertions(+), 0 deletions(-) create mode 100644 src/modules/module-null-source.c This module isn't actually used by anyone currently. We (at Nokia) switched to null-sink's monitor a long time ago (for reasons unknown to me), so the code hasn't had much testing lately. Even though there are no users for the module currently, I'm sending the patch anyway, just in case people think that the module might be useful in some situation. I quickly tested that I can record silence with parec from source.null - I can't give any further guarantees that the code is correct. Yeah due to the fact that a null sink has a null monitor, this module is of limited usefulness, but I think it could still be useful in some cases where you do want a null recording but don't want it polluted with sinks. I did actually have someone that wanted to hook up null sources and null sinks to some Windows VMs a while back (several VMs but only one null sink+monitor source). He was annoyed that he could record other VMs output from within a separate VM on the monitor. Obviously he can shuffle around the various streams and create multiple null sinks but it would have actually been simpler to setup a null source in the first place. So I'll do some testing then grab it at some point (tho' need to spend some time reviewing Margarita's work before next week otherwise Liam and Mark will find some way to punish me!) FYI, I've done some review of that code already, and I agree with plbossart's comments recently about the jack detection being done the wrong way. In addition, I don't think we (as in Canonical/Ubuntu) even got it to work yet even though we've tried it several times. You can see some of it here: https://bugs.launchpad.net/ubuntu/+source/alsa-lib/+bug/746023 So I don't think it's ready. The question about how we can make it ready might be a topic for next week's conference perhaps. See you! -- 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] [PATCH] module: new null-source module
On 2011-04-27 16:55, David Henningsson wrote: So I'll do some testing then grab it at some point (tho' need to spend some time reviewing Margarita's work before next week otherwise Liam and Mark will find some way to punish me!) FYI, I've done some review of that code already, and I agree with plbossart's comments recently about the jack detection being done the wrong way. In addition, I don't think we (as in Canonical/Ubuntu) even got it to work yet even though we've tried it several times. You can see some of it here: https://bugs.launchpad.net/ubuntu/+source/alsa-lib/+bug/746023 So I don't think it's ready. The question about how we can make it ready might be a topic for next week's conference perhaps. See you! Hmm, that was not supposed to go to the list.. *blushes* Anyway, I haven't been much involved with the ucm stuff until a few weeks ago, but I'll see next week (during either the ASoC conference, LAC, or UDS) if I can grab one of these pandaboards, play around a little with UCM and get it explained to me (alsaucm could use a man page!), and see if I can understand why we never got those patches to work reliably in Ubuntu 11.04. -- 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] [PATCH] module: new null-source module
On 2011-04-27 20:06, Mark Brown wrote: On Wed, Apr 27, 2011 at 05:07:44PM +0200, David Henningsson wrote: Adding Marga and Liam, not cutting text as a result. On 2011-04-27 16:55, David Henningsson wrote: So I'll do some testing then grab it at some point (tho' need to spend some time reviewing Margarita's work before next week otherwise Liam and Mark will find some way to punish me!) FYI, I've done some review of that code already, and I agree with plbossart's comments recently about the jack detection being done the wrong way. In addition, I don't think we (as in Canonical/Ubuntu) even got it to work yet even though we've tried it several times. You can see some of it here: https://bugs.launchpad.net/ubuntu/+source/alsa-lib/+bug/746023 So I don't think it's ready. The question about how we can make it ready might be a topic for next week's conference perhaps. See you! Hmm, that was not supposed to go to the list.. *blushes* Anyway, I haven't been much involved with the ucm stuff until a few weeks ago, but I'll see next week (during either the ASoC conference, LAC, or UDS) if I can grab one of these pandaboards, play around a little with UCM and get it explained to me (alsaucm could use a man page!), and see if I can understand why we never got those patches to work reliably in Ubuntu 11.04. You're not really supposed to use alsaucm directly except for testing and developing new configurations, That's reason enough to have a man page and some documentation, if you ask me. (Not claiming you're the only one missing documentation though.) I'd not expect it to play nicely with an application that's also driving UCM. Sounds from a brief scan like the issue with the defaults getting lost on boot is that Pulse needs to start storing the state itself (I'd expect on a per use case basis) rather than relying on something else doing so underneath it. Trying to restore a state which may correspond to a totally different use case is going to be fail, and restoring state that is part of the use cases has obvious issues too. But I've not read the report properly so I'm mostly just guessing here. The overall problem IMHO is that it is overly complex: 1) The kernel might set some basic volumes 2) Alsactl can store/restore volumes 3) Alsaucm can set volumes 4) PulseAudio (for the gdm user) can store/restore volumes 5) PulseAudio (for the logged on user) can store/restore volumes As UCM adds yet another complexity to the equation, we need to get it right, avoid races and so on. If possible, I'd like to cut away a layer or two for simplicity and optimisation. Btw, as I understand it, the code in PA for controlling hardware volumes through UCM is not yet a part of Maggie's patches. Is that correct? -- 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
[pulseaudio-discuss] [PATCH] Alsa-plugins: Pulse: Fix snd_pcm_avail returning 0 in some cases
Due to a round-off error, snd_pcm_avail could in some cases
return 0 even though more data could be written to the stream.
This was discovered by Maarten Lankhorst [1], and there is also a test
program available that triggers this error [2].
[1]
https://tango.0pointer.de/pipermail/pulseaudio-discuss/2011-April/009935.html
[2]
https://tango.0pointer.de/pipermail/pulseaudio-discuss/attachments/20110420/3c852d6e/attachment.c
--
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic
From 73ff6f83e1e4c53181e1794bf2cec3baee7c81b7 Mon Sep 17 00:00:00 2001
From: David Henningsson david.hennings...@canonical.com
Date: Thu, 21 Apr 2011 15:10:19 +0200
Subject: [PATCH] Pulse: Fix snd_pcm_avail returning 0 in some cases
Due to a round-off error, snd_pcm_avail could in some cases
return 0 even though more data could be written to the stream.
Reported-by: Maarten Lankhorst m.b.lankho...@gmail.com
Signed-off-by: David Henningsson david.hennings...@canonical.com
---
pulse/pcm_pulse.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/pulse/pcm_pulse.c b/pulse/pcm_pulse.c
index 2df0a80..9105d4d 100644
--- a/pulse/pcm_pulse.c
+++ b/pulse/pcm_pulse.c
@@ -92,8 +92,8 @@ static int update_ptr(snd_pcm_pulse_t *pcm)
size -= pcm-offset;
/* Prevent accidental overrun of the fake ringbuffer */
- if (size = pcm-buffer_attr.tlength)
- size = pcm-buffer_attr.tlength-1;
+ if (size pcm-buffer_attr.tlength - pcm-frame_size)
+ size = pcm-buffer_attr.tlength - pcm-frame_size;
if (size pcm-last_size) {
pcm-ptr += size - pcm-last_size;
--
1.7.4.1
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] underrun behavior with alsa-plugins
On 2011-04-19 18:12, Maarten Lankhorst wrote: Hi all, For wine I was investigating a bug with pulseaudio, it seems alsa-plugins' pulse driver ignores underruns. Hmm, doesn't wine come with a native pulse driver these days? This is probably because an underrun will force you to call snd_pcm_prepare, this will destroy the stream and set up a similar new one again. ...whereas the proper way to resolve the underrun in the pulse plugin is just to feed it with more data, which is likely what would happen if you do not report the underrun. This causes more susceptibility to underruns, so that code was disabled. Takashi added some kind of option so you can turn the reporting of underruns on again, if that helps. However if I force underruns to occur,the state will stay running and it appears there is still some data left in the buffer, so sound stalls entirely. This is nothing I've heard of. The latency gets updated to something like 0x7bdX which looks suspiciously much like a pointer to me, which may be a bug. If I instead make pulse_prepare call pulse_start on underrun, it's handled properly and sound will continue to work. So my questions are. 1. Is the weird latency value update a bug? I guess so, but what sense would it make to read the latency if you're in an underrun condition - and btw, exactly what latency variable is this? Digging it up I can only assume it's a bug in src/stream.c , but I haven't figured out why yet. Tested with pulseaudio.c 2. Any comments on this patch for alsa-plugins? IIRC, by setting handle_underrun to 1, you're reopening bugs of broken/skipping audio for mpg123 and other programs, which get stuck in an infinite loop of write one sample, force start the stream, write more samples, asynchronusly get an underrun, drop the stream and drop samples already written. There should be threads on at least alsa-devel about this, from a year back or so. -- 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] underrun behavior with alsa-plugins
On 2011-04-20 12:09, Maarten Lankhorst wrote: Hi David, Op 20-04-11 09:33, David Henningsson schreef: On 2011-04-19 18:12, Maarten Lankhorst wrote: Hi all, For wine I was investigating a bug with pulseaudio, it seems alsa-plugins' pulse driver ignores underruns. Hmm, doesn't wine come with a native pulse driver these days? Nope, but distros patch in a buggy winepulse driver, wine is working on rearchitecting its driver model, so that a pulseaudio driver might be added after that, but the current winepulse driver was a bad copy/replace job of the wrong sound driver. :) This is probably because an underrun will force you to call snd_pcm_prepare, this will destroy the stream and set up a similar new one again. ...whereas the proper way to resolve the underrun in the pulse plugin is just to feed it with more data, which is likely what would happen if you do not report the underrun. This causes more susceptibility to underruns, so that code was disabled. Takashi added some kind of option so you can turn the reporting of underruns on again, if that helps. If you read my patch, that's what it does. However if I force underruns to occur,the state will stay running and it appears there is still some data left in the buffer, so sound stalls entirely. This is nothing I've heard of. Sadly all too common here, if I feed data and it underruns, it may appear to be running but is stalled entirely. Could you provide a test case where this occurs? (Pulseaudio/ALSA version, client applications/libraries, etc) The latency gets updated to something like 0x7bdX which looks suspiciously much like a pointer to me, which may be a bug. If I instead make pulse_prepare call pulse_start on underrun, it's handled properly and sound will continue to work. So my questions are. 1. Is the weird latency value update a bug? I guess so, but what sense would it make to read the latency if you're in an underrun condition - and btw, exactly what latency variable is this? In a response to a latency event I printf the latency inside the callback, with pa_stream_get_latency. Digging it up I can only assume it's a bug in src/stream.c , but I haven't figured out why yet. Tested with pulseaudio.c 2. Any comments on this patch for alsa-plugins? IIRC, by setting handle_underrun to 1, you're reopening bugs of broken/skipping audio for mpg123 and other programs, which get stuck in an infinite loop of write one sample, force start the stream, write more samples, asynchronusly get an underrun, drop the stream and drop samples already written. There should be threads on at least alsa-devel about this, from a year back or so. This is exactly what my patch was addressing, I was fixing that bug by handling underrun correctly. snd_pcm_prepare() is called when an underrun occurs, so instead I make it only restart the stream if underrun. Not handling underruns at all seems to allow it to stall on xrun, while claiming to be running. This sometimes appears to happen in other programs too though, like mplayer. Could it be because of the weird latency value? Ok, thanks for the clarifications. I've taken a closer look at your patch now and have the following comments: When you're calling pulse_start instead of continuing in pulse_prepare - pulse_start will call uncork/trigger, won't that just cause another underrun? Would it perhaps be better to just return without doing anything? mpg123 was used as a test case for the original bug, and mpg123 calls snd_pcm_drop on an underrun, so you will be regressing mpg123 by changing handle_underrun to 1. (Now of course we could fix mpg123, but I don't know if there are a lot of other programs out there doing similar things?) My main point is that the underrun is often obsolete when the message reached the application, because more data has already been written, therefore reporting it to the app does more harm than good. At least until the underrun callback (and PA protocol) supports sending the position of underrun, together with the underrun message. If we had that position, we could compare that with the current write pointer to determine whether the underrun is actually obsolete or not. -- 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
[pulseaudio-discuss] Crash in RAOP sink
I'm trying to fix a crash a few people have encountered in the upcoming
version of Ubuntu, which uses 0.9.22 plus a few stable-queue patches.
It crashes with an assertion failure at
modules/raop/module-raop-sink.c:246. As I don't know much about these
RAOP things, the below was the best I could come up with. Any thoughts?
Here's a link to the stack trace:
https://i68752006.restricted.launchpadlibrarian.net/68752006/ThreadStacktrace.txt?token=492a8975a0bfe5d32e7feca41d576110
diff --git a/src/modules/raop/module-raop-sink.c
b/src/modules/raop/module-raop-sink.c
index 466488e..edeb542 100644
--- a/src/modules/raop/module-raop-sink.c
+++ b/src/modules/raop/module-raop-sink.c
@@ -243,9 +243,8 @@ static int sink_process_msg(pa_msgobject *o, int
code, void *data, int64_t offse
}
case SINK_MESSAGE_RIP_SOCKET: {
-pa_assert(u-fd = 0);
-
-pa_close(u-fd);
+if (u-fd = 0)
+pa_close(u-fd);
u-fd = -1;
if (u-sink-thread_info.state == PA_SINK_SUSPENDED) {
--
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] Crash in RAOP sink
On 2011-04-15 11:49, David Henningsson wrote:
I'm trying to fix a crash a few people have encountered in the upcoming
version of Ubuntu, which uses 0.9.22 plus a few stable-queue patches.
Actually there's a different set of crashes at
modules/raop/module-raop-sink.c:230 as well:
case SINK_MESSAGE_PASS_SOCKET: {
struct pollfd *pollfd;
pa_assert(!u-rtpoll_item); --- crashes here
An example stack trace is here:
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/753394/+attachment/1993351/+files/ThreadStacktrace.txt
It crashes with an assertion failure at
modules/raop/module-raop-sink.c:246. As I don't know much about these
RAOP things, the below was the best I could come up with. Any thoughts?
Here's a link to the stack trace:
https://i68752006.restricted.launchpadlibrarian.net/68752006/ThreadStacktrace.txt?token=492a8975a0bfe5d32e7feca41d576110
Corrected link for the other stack trace type:
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/755166/+attachment/2003582/+files/ThreadStacktrace.txt
--
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] [PATCH 4/4] alsa-mixer: Add force-hw-volume flag to alsa profile sets
On 2011-04-08 17:18, Colin Guthrie wrote: 'Twas brillig, and o...@iki.fi at 08/04/11 15:18 did gyre and gimble: From: Jyri Sarhajyri.sa...@nokia.com Before this patch, if any of the paths in a path set do not support HW volume then the HW volume is disabled for the whole set. In some cases this is a bit drastic measure. For instance, if all but one of the paths support HW volume and dB there no problem to pretend that we have HW volume for the whole set. The path without any mixers to control will just always return 0 dB and the rest is handled by SW volume. This patch adds a flag to the mapping section of profile set file to enables this behavior. David, this sounds similar to your USB Headset issue from a couple days ago... or am I just reading too much into the description? Sort of - it just feels like neither of us has tried to do the right thing so far - I added a workaround/quirk for a few devices, and this patch adds a setting to turn something on and off. I'd like it to just work. Or put in another way - what's the recommended default setting of this new parameter, and why? // David ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 6/6] alsa: load jack detection module
Hi Margarita,
I have a question, maybe you can explain to me (see below) :
On 2011-04-05 22:34, Margarita Olaya wrote:
@@ -352,6 +372,40 @@ static void verify_access(struct userdata *u,
struct device *d) {
}
}
+static void verify_input_access(struct userdata *u, struct device *d) {
+char *cd;
+char *args;
+pa_card *card;
(The card variable is not used in the function.)
+pa_bool_t accessible;
+
+pa_assert(u);
+pa_assert(d);
+
+cd = pa_sprintf_malloc(%s/input/event%s,
udev_get_dev_path(u-udev), path_get_input_id(d-path));
+accessible = access(cd, R_OK)= 0;
+pa_log_debug(%s is accessible: %s, cd, pa_yes_no(accessible));
+
+if (d-module == PA_INVALID_INDEX) {
+
+/* If we are not loaded, try to load */
+if (accessible) {
+pa_module *m;
+
+args = pa_sprintf_malloc(device_id=\%s\
+card_name=\%s\ , cd, d-card_name);
It seems like d-card_name is only set in card_changed, which is not
called for input devices. Won't this card name always be empty?
Also, if a card is marked PULSE_IGNORE, will that make the card's input
devices to be ignored as well? Before starting the module jack detection
module, can you make sure that the card is loaded by PA?
--
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] [PATCH] alsa-mixer: Add workaround for some USB headsets
On 2011-04-05 22:57, Colin Guthrie wrote: 'Twas brillig, and David Henningsson at 05/04/11 13:03 did gyre and gimble: As I discussed with Tanu Kaskinen yesterday, we should do something about when one profile path prevents another from using the hw volume capabilities. However, with Ubuntu a few weeks from release, I went for the workaround approach and created a separate profile for the devices instead to minimise regression potential. So, until this is fixed the right way, feel free to use the attached patch. Bug reference: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/671560 While I appreciate this is a work around, is it worth committing (especially to stable-queue) in the short term? We'll likely push out stable-queue very soon. If you've got a fairly recent snapshot for Ubuntu already, then bumping the version to 0.9.23 should be uncontroversial (tho' version bumps may still be banned by policy regardless). What do you think? Col Good question. Maybe it would make more sense for distro maintainers than upstream. I guess it also depends on when someone actually makes the fix the right way :-) -- 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] [PATCH 5/6] alsa: create ucm profiles
On 2011-04-05 22:34, Margarita Olaya wrote:
+static pa_hook_result_t jack_insert_new_hook_callback(pa_core *c,
struct userdata *u) {
+struct pa_alsa_ucm_config *ucm =u-ucm;
+struct profile_data *d;
+char *device_name;
+
+pa_assert(u);
+
+d = PA_CARD_PROFILE_DATA(u-card-active_profile);
+
+pa_log_debug(Jack insert new hook callback);
+
+device_name = strchr(d-profile-name, ':') + 2;
+if (!device_name) {
+pa_log(no device found for %s, d-profile-name);
+return PA_HOOK_CANCEL;
+}
+
+if (strcmp(device_name, Headset.0) == 0)
+return PA_HOOK_OK;
+
+/* Set headset.0 device per default */
+if (snd_use_case_set(ucm-ucm_mgr, _enadev, Headset.0) 0) {
+pa_log(failed to set device Headset.0);
+return PA_HOOK_CANCEL;
+}
+
+return PA_HOOK_OK;
+}
About this function:
1) pa_hook_cb_t defines three pointers as input, but this one only takes
two. Is that really working on all platforms?
2) There is no matching against what card sent the event, is that
irrelevant for UCM?
3) Is Headset.0 a reserved identifier in UCM, or is this unfinished
test code? What if there isn't a headset, just a separate external mic,
or external speakers connected to line out?
+
+static pa_hook_result_t jack_remove_new_hook_callback(pa_core *c,
struct userdata *u) {
+struct profile_data *d;
+struct pa_alsa_ucm_config *ucm =u-ucm;
+char *device_name;
+
+pa_assert(u);
+
+d = PA_CARD_PROFILE_DATA(u-card-active_profile);
+
+pa_log_debug(Jack removed new hook callback);
+
+device_name = strchr(d-profile-name, ':') + 2;
+if(!device_name) {
+pa_log(no device found for %s, d-profile-name);
+return PA_HOOK_CANCEL;
+}
+
+/* Set current profile device */
+if (snd_use_case_set(ucm-ucm_mgr, _enadev, Headset.0) 0) {
+pa_log(failed to set device Headset.0);
+return PA_HOOK_CANCEL;
+}
+
+return PA_HOOK_OK;
+}
Ehm, seems like you set it to the Headset device both on plug and unplug...?
--
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
[pulseaudio-discuss] [PATCH] alsa-mixer: Add workaround for some USB headsets
As I discussed with Tanu Kaskinen yesterday, we should do something
about when one profile path prevents another from using the hw volume
capabilities. However, with Ubuntu a few weeks from release, I went for
the workaround approach and created a separate profile for the devices
instead to minimise regression potential.
So, until this is fixed the right way, feel free to use the attached patch.
Bug reference:
https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/671560
--
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic
From 6f41a4140013dac7737847bb5eddc78906eb09b7 Mon Sep 17 00:00:00 2001
From: David Henningsson david.hennings...@canonical.com
Date: Tue, 5 Apr 2011 11:37:59 +0200
Subject: [PATCH] alsa-mixer: Add workaround for some USB headsets
This is a workaround - these usb headsets have one output volume
control only, labeled Speaker. This causes the default profile
set to not control the volume at all, which is a bug. Workaround
that by creating a separate profile set.
Signed-off-by: David Henningsson david.hennings...@canonical.com
---
src/Makefile.am|3 +-
.../alsa/mixer/profile-sets/90-pulseaudio.rules|3 ++
.../alsa/mixer/profile-sets/usb-headset.conf | 35
3 files changed, 40 insertions(+), 1 deletions(-)
create mode 100644 src/modules/alsa/mixer/profile-sets/usb-headset.conf
diff --git a/src/Makefile.am b/src/Makefile.am
index cc38db2..0a4862f 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -115,7 +115,8 @@ ALSA_PROFILES = \
modules/alsa/mixer/profile-sets/native-instruments-audio4dj.conf \
modules/alsa/mixer/profile-sets/native-instruments-audio8dj.conf \
modules/alsa/mixer/profile-sets/native-instruments-traktorkontrol-s4.conf \
- modules/alsa/mixer/profile-sets/native-instruments-korecontroller.conf
+ modules/alsa/mixer/profile-sets/native-instruments-korecontroller.conf \
+ modules/alsa/mixer/profile-sets/usb-headset.conf
ALSA_PATHS = \
modules/alsa/mixer/paths/analog-input-aux.conf \
diff --git a/src/modules/alsa/mixer/profile-sets/90-pulseaudio.rules b/src/modules/alsa/mixer/profile-sets/90-pulseaudio.rules
index f964b00..ff91ccf 100644
--- a/src/modules/alsa/mixer/profile-sets/90-pulseaudio.rules
+++ b/src/modules/alsa/mixer/profile-sets/90-pulseaudio.rules
@@ -20,6 +20,9 @@ SUBSYSTEM!=sound, GOTO=pulseaudio_end
ACTION!=change, GOTO=pulseaudio_end
KERNEL!=card*, GOTO=pulseaudio_end
+SUBSYSTEMS==usb, ATTRS{idVendor}==046d, ATTRS{idProduct}==01ab, ENV{PULSE_PROFILE_SET}=usb-headset.conf
+SUBSYSTEMS==usb, ATTRS{idVendor}==046d, ATTRS{idProduct}==0a0c, ENV{PULSE_PROFILE_SET}=usb-headset.conf
+SUBSYSTEMS==usb, ATTRS{idVendor}==1395, ATTRS{idProduct}==0002, ENV{PULSE_PROFILE_SET}=usb-headset.conf
SUBSYSTEMS==usb, ATTRS{idVendor}==17cc, ATTRS{idProduct}==1978, ENV{PULSE_PROFILE_SET}=native-instruments-audio8dj.conf
SUBSYSTEMS==usb, ATTRS{idVendor}==17cc, ATTRS{idProduct}==0839, ENV{PULSE_PROFILE_SET}=native-instruments-audio4dj.conf
SUBSYSTEMS==usb, ATTRS{idVendor}==17cc, ATTRS{idProduct}==baff, ENV{PULSE_PROFILE_SET}=native-instruments-traktorkontrol-s4.conf
diff --git a/src/modules/alsa/mixer/profile-sets/usb-headset.conf b/src/modules/alsa/mixer/profile-sets/usb-headset.conf
new file mode 100644
index 000..adf78d1
--- /dev/null
+++ b/src/modules/alsa/mixer/profile-sets/usb-headset.conf
@@ -0,0 +1,35 @@
+# This file is part of PulseAudio.
+#
+# PulseAudio is free software; you can redistribute it and/or modify
+# it under the terms of the GNU Lesser General Public License as
+# published by the Free Software Foundation; either version 2.1 of the
+# License, or (at your option) any later version.
+#
+# PulseAudio is distributed in the hope that it will be useful, but
+# WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+# General Public License for more details.
+#
+# You should have received a copy of the GNU Lesser General Public License
+# along with PulseAudio; if not, write to the Free Software Foundation,
+# Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+
+; This is a workaround - these usb headsets have one output volume control only, labeled Speaker.
+; This causes the default profile set to not control the volume at all, which is a bug.
+
+[General]
+auto-profiles = yes
+
+[Mapping analog-mono]
+device-strings = hw:%f
+channel-map = mono
+paths-output = analog-output-speaker
+paths-input = analog-input analog-input-mic analog-input-linein analog-input-aux analog-input-video analog-input-tvtuner analog-input-fm analog-input-mic-line
+priority = 1
+
+[Mapping analog-stereo]
+device-strings = front:%f hw:%f
+channel-map = left,right
+paths-output = analog-output-speaker
+paths-input = analog-input analog-input-mic analog-input-linein analog-input-aux analog-input-video analog-input-tvtuner analog-input-fm analog-input-mic-line
+priority = 10
--
1.7.4.1
[pulseaudio-discuss] [PATCH] module-jack-sink/source: protect against null return in jack_get_ports
Just picking up a crash report from Ubuntu, here's the result.
--
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic
From 934c52c79bb6faed56a64d6e15f9b285f687afee Mon Sep 17 00:00:00 2001
From: David Henningsson david.hennings...@canonical.com
Date: Mon, 28 Mar 2011 14:30:44 +0200
Subject: [PATCH] module-jack-sink/source: protect against null return in jack_get_ports
According to jack_get_ports documentation, it seems like returning NULL
is valid, and that it should be freed using jack_free.
Reported-by: Grayson Peddie
BugLink: http://bugs.launchpad.net/bugs/733424
Signed-off-by: David Henningsson david.hennings...@canonical.com
---
src/modules/jack/module-jack-sink.c | 13 -
src/modules/jack/module-jack-source.c | 13 -
2 files changed, 16 insertions(+), 10 deletions(-)
diff --git a/src/modules/jack/module-jack-sink.c b/src/modules/jack/module-jack-sink.c
index 08a8bef..706f358 100644
--- a/src/modules/jack/module-jack-sink.c
+++ b/src/modules/jack/module-jack-sink.c
@@ -343,8 +343,9 @@ int pa__init(pa_module*m) {
ports = jack_get_ports(u-client, NULL, JACK_DEFAULT_AUDIO_TYPE, JackPortIsPhysical|JackPortIsInput);
channels = 0;
-for (p = ports; *p; p++)
-channels++;
+if (ports)
+for (p = ports; *p; p++)
+channels++;
if (!channels)
channels = m-core-default_sample_spec.channels;
@@ -432,7 +433,7 @@ int pa__init(pa_module*m) {
if (do_connect) {
for (i = 0, p = ports; i ss.channels; i++, p++) {
-if (!*p) {
+if (!p || !*p) {
pa_log(Not enough physical output ports, leaving unconnected.);
break;
}
@@ -448,7 +449,8 @@ int pa__init(pa_module*m) {
pa_sink_put(u-sink);
-free(ports);
+if (ports)
+jack_free(ports);
pa_modargs_free(ma);
return 0;
@@ -457,7 +459,8 @@ fail:
if (ma)
pa_modargs_free(ma);
-free(ports);
+if (ports)
+jack_free(ports);
pa__done(m);
diff --git a/src/modules/jack/module-jack-source.c b/src/modules/jack/module-jack-source.c
index 6b12840..8453bd9 100644
--- a/src/modules/jack/module-jack-source.c
+++ b/src/modules/jack/module-jack-source.c
@@ -289,8 +289,9 @@ int pa__init(pa_module*m) {
ports = jack_get_ports(u-client, NULL, JACK_DEFAULT_AUDIO_TYPE, JackPortIsPhysical|JackPortIsOutput);
channels = 0;
-for (p = ports; *p; p++)
-channels++;
+if (ports)
+for (p = ports; *p; p++)
+channels++;
if (!channels)
channels = m-core-default_sample_spec.channels;
@@ -376,7 +377,7 @@ int pa__init(pa_module*m) {
if (do_connect) {
for (i = 0, p = ports; i ss.channels; i++, p++) {
-if (!*p) {
+if (!p || !*p) {
pa_log(Not enough physical output ports, leaving unconnected.);
break;
}
@@ -393,7 +394,8 @@ int pa__init(pa_module*m) {
pa_source_put(u-source);
-free(ports);
+if (ports)
+jack_free(ports);
pa_modargs_free(ma);
return 0;
@@ -402,7 +404,8 @@ fail:
if (ma)
pa_modargs_free(ma);
-free(ports);
+if (ports)
+jack_free(ports);
pa__done(m);
--
1.7.4.1
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] ALSA or PulseAudio for low-latency voice?
On 2011-03-19 17:45, Philip Jägenstedt wrote: Hi PulseAudionauts, I've been meaning to experiment a bit with low-latency voice codecs and naturally want to add as little latency as possible to what is imposed by the codec on both capture and playback. (My guess is that the latency added would be between min(capture_latency, playback_latency) and capture_latency+playback_latency, depending on how well capture end and playback begin are synchronized.) Q: Does it matters for latency if I program against ALSA or PulseAudio? Well, that kind of depends on what scale you're on. If you need latencies under say - and this is just a qualified guess - ~ 10-20 ms, you'll need to program against ALSA or Jack. Above that and you'll be good with PulseAudio. This is assuming a setup like on Ubuntu, where the default ALSA device is using a PulseAudio backend. (Portability and code complexity may favor one solution or the other, but that's not what I'm asking.) When I say program against ALSA above, I mean directly against an ALSA sound card, i e bypassing Pulseaudio. As for if ALSA plugin - PulseAudio - ALSA - HW gives worse latency than PulseAudio - ALSA - HW, I don't think that matters much. -- 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] [RFC] Pulseaudio jack sense
On 2011-03-10 22:47, Margarita Olaya wrote: Hi, I have some initial code for jack sense implementation, the approach is to listen /dev/input/eventX and pass that data as argument to a new module called module-jack-detect where a thread wakes when the jack has been inserted. Using the current code I'm able to catch jack insertion and removal, next step is to signal PA core when the jack has been inserted so this calls a hook in the PA UCM module to load the ucm configuration for jack. Jack sense is something that we all want, so it's great that someone is working on it. The first tricky thing is to match /dev/input/eventX against the proper card - that is, if you have three cards, all with headphone outputs, you must know which card your event belongs to. Is this solved in your git tree? I had a quick look but couldn't find code for doing that. (You also seem to add threads for all eventX, even those not audio related at all, could this be improved?) So, I need to send a message to any other interested module but I'm sure how implement it, Can a hook be used to signal PA core? The second thing is to figure out what we should really do once we have detected jack insertion or removal. Adding a hook event and let other modules act on that, seems reasonable to me. But we should also add a property to the property list (or something similar?) telling the current state of the jack - and btw, can this be figured out by reading from /dev/input/eventX at startup? -- 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] [PATCH 0/7] Working around bad decibel information
On 2011-03-04 16:42, Tanu Kaskinen wrote: Here's a pile of patches. The first two implement the concept of decibel fixes for alsa devices. A decibel fix is basically a table that maps the raw volume steps of a mixer element to manually configured decibel values. Hmm, taking Lennart's hat on, shouldn't bad decibel information be fixed in the kernel, rather than in Pulseaudio? Then other non-PA applications would benefit from the change as well. -- 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
[pulseaudio-discuss] [RFC PATCH] Profile for Nvidia
This patch is RFC both because I haven't tested it properly yet
(although I expect it to work!) but mainly because I'm uncertain of what
surround profiles we should add for HDMI. Opinions about that or other
patches?
I don't think it relates to Kelly's patch posted earlier this week or
other pass-through patches.
--
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic
From 8438e14d1101f195e4c1a5dff41fdbacbc9366df Mon Sep 17 00:00:00 2001
From: David Henningsson david.hennings...@canonical.com
Date: Tue, 8 Mar 2011 10:51:33 +0100
Subject: [PATCH] alsa-mixer: Add separate profile for Nvidia
This is a profile for all Nvidia cards - some Nvidia cards have four HDMI codecs,
and which ones are working seems to vary a lot between GPU boards. In addition,
Nvidia makes southbridges as well, so we need to keep the existing analog profiles.
(And by not adding all these extra profiles to default.conf, we make sure
there is no performance hit for non-Nvidia cards.)
Once we have proper jack detection, there would probably be room for improvement here.
Signed-off-by: David Henningsson david.hennings...@canonical.com
---
src/Makefile.am|1 +
.../alsa/mixer/profile-sets/90-pulseaudio.rules|1 +
src/modules/alsa/mixer/profile-sets/nvidia.conf| 160
3 files changed, 162 insertions(+), 0 deletions(-)
create mode 100644 src/modules/alsa/mixer/profile-sets/nvidia.conf
diff --git a/src/Makefile.am b/src/Makefile.am
index ec301da..4fc68a6 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -109,6 +109,7 @@ MODULE_LDFLAGS = -module -disable-static -avoid-version $(LDFLAGS_NOUNDEFINED)
ALSA_PROFILES = \
modules/alsa/mixer/profile-sets/default.conf \
+ modules/alsa/mixer/profile-sets/nvidia.conf \
modules/alsa/mixer/profile-sets/maudio-fasttrack-pro.conf \
modules/alsa/mixer/profile-sets/native-instruments-audio4dj.conf \
modules/alsa/mixer/profile-sets/native-instruments-audio8dj.conf \
diff --git a/src/modules/alsa/mixer/profile-sets/90-pulseaudio.rules b/src/modules/alsa/mixer/profile-sets/90-pulseaudio.rules
index f964b00..3b7078f 100644
--- a/src/modules/alsa/mixer/profile-sets/90-pulseaudio.rules
+++ b/src/modules/alsa/mixer/profile-sets/90-pulseaudio.rules
@@ -25,5 +25,6 @@ SUBSYSTEMS==usb, ATTRS{idVendor}==17cc, ATTRS{idProduct}==0839, ENV{PULSE_
SUBSYSTEMS==usb, ATTRS{idVendor}==17cc, ATTRS{idProduct}==baff, ENV{PULSE_PROFILE_SET}=native-instruments-traktorkontrol-s4.conf
SUBSYSTEMS==usb, ATTRS{idVendor}==17cc, ATTRS{idProduct}==4711, ENV{PULSE_PROFILE_SET}=native-instruments-korecontroller.conf
SUBSYSTEMS==usb, ATTRS{idVendor}==0763, ATTRS{idProduct}==2012, ENV{PULSE_PROFILE_SET}=maudio-fasttrack-pro.conf
+ATTRS{idVendor}==10de, ENV{PULSE_PROFILE_SET}=nvidia.conf
LABEL=pulseaudio_end
diff --git a/src/modules/alsa/mixer/profile-sets/nvidia.conf b/src/modules/alsa/mixer/profile-sets/nvidia.conf
new file mode 100644
index 000..69a371f
--- /dev/null
+++ b/src/modules/alsa/mixer/profile-sets/nvidia.conf
@@ -0,0 +1,160 @@
+# This file is part of PulseAudio.
+#
+# PulseAudio is free software; you can redistribute it and/or modify
+# it under the terms of the GNU Lesser General Public License as
+# published by the Free Software Foundation; either version 2.1 of the
+# License, or (at your option) any later version.
+#
+# PulseAudio is distributed in the hope that it will be useful, but
+# WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+# General Public License for more details.
+#
+# You should have received a copy of the GNU Lesser General Public License
+# along with PulseAudio; if not, write to the Free Software Foundation,
+# Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+
+; This is a profile for all Nvidia cards - some Nvidia cards have four HDMI codecs,
+; and which ones are working seems to vary a lot between GPU boards. In addition,
+; Nvidia makes southbridges as well, so we need to keep the existing analog profiles.
+; (And by not adding all these extra profiles to default.conf, we make sure
+; there is no performance hit for non-Nvidia cards.)
+
+; Once we have proper jack detection, there would probably be room for improvement here.
+
+[General]
+auto-profiles = yes
+
+[Mapping analog-mono]
+device-strings = hw:%f
+channel-map = mono
+paths-output = analog-output analog-output-speaker analog-output-desktop-speaker analog-output-headphones analog-output-headphones-2 analog-output-mono analog-output-lfe-on-mono
+paths-input = analog-input analog-input-mic analog-input-linein analog-input-aux analog-input-video analog-input-tvtuner analog-input-fm analog-input-mic-line
+priority = 1
+
+[Mapping analog-stereo]
+device-strings = front:%f hw:%f
+channel-map = left,right
+paths-output = analog-output analog-output-speaker analog-output-desktop-speaker analog-output-headphones analog-output-headphones-2
Re: [pulseaudio-discuss] Conexant CX20585 recording does not work
On 2011-03-08 00:26, Colin Guthrie wrote: 'Twas brillig, and Gabriel Schulhof at 07/03/11 19:56 did gyre and gimble: Hi! My mom has a laptop with the following sound card: lspci: 00:14.2 Audio device: ATI Technologies Inc SBx00 Azalia (Intel HDA) (rev 40) driver: snd_hda_intel alsamixer: Card: HDA ATI SB Chip: Conexant CX20585 I can't record from this card no matter what I try. It seems that alsamixer has a lot more options than pulseaudio: Mic BCapture switch Mic CCapture switch Mic ECapture switch Mic FCapture switch Capture0% -- 100% slider Analog Mic Boost0 db -- 40 db slider with 10 db increment Nevertheless, I will attach the output from pacmd list-sources. I have tried to record from each mic in turn, I have tried the different boost levels (0 db - 40 db), but I have had no luck picking up anything. I have attached an external mic to the line-in, but no difference. When I say I have tried to record I mean that I logged into her computer, chose one of the mics from the above list, and then I told my mom to say something while looking at the input sound level indicator in the GNOME sound settings panel. On other computers, I have found this a sufficient indication of whether the mic works. Is this inability to record a known limitation of this sound card? If not, is there some special setting I have to modify to make it work? TIA for your help, Some mics do this weird out-of-phase thing whereby the recording level is effectively 0 when the stereo volume is synced. If you set left to say 5% and right to say 95% then it works fine. This may be the case with your h/w too. FWIW The extra options you see in ALSA are generally confusing and useless. PA attempts to consolidate it and make it a lot more user friendly. Normally you'd get a list of several port selectors in gnome-volume-control. Sadly as your card uses the incredibly helpful names of Mic B through Mic F these do not match the various standard names we probe for. David, have you come across this model on your travels? Many times, that's the fallback for many Conexants. Any ideas on how we could best support it? This one is one of few that lack an auto-parser of the pin default config, so for now - model quirks. Without seeing alsa-info or something similar, I can't tell which model would fit. In the long run we would benefit from an autoparser handling these as well. -- 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] unused check_required function in modules/alsa/alsa-mixer.c
On 2011-03-03 17:54, Maarten Bosmans wrote: I intended to catch diwic on IRC, but didn't see him the last couple of days, so in order not to forget, here is my question to the list. In this commit some stuff got shuffled around in alsa-mixer http://git.0pointer.de/?p=pulseaudio.git;a=commitdiff;h=b0f72311 With the result that the check_required function is now unused (or more precise: only used by itself). This is probably incorrect. David, can you explain/fix? Hmm, in my patch as posted months ago, the call to check_required was moved inside the element_probe function only, not moved from element_probe to check_required. Colin, can anything have gone wrong when you merged it? -- 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] Questions about no ports available to select.
On 2011-02-23 04:19, fykc...@gmail.com wrote: Hi David, Thanks for your reply! 2011/2/22 David Henningssondavid.hennings...@canonical.com Your log indicates your HDA codec is a Conexant ID 506e - the Conexant driver does not yet support this codec, so the driver falls back to a generic driver. I intend to make a new attempt later this week to add a quirk for that particular chip. If you, in the meantime, could point me to a bug in Launchpad (filed with the ubuntu-bug audio command), that would be helpful, as that would include valuable codec info. Thanks! I'm not running ubuntu, just using that package from ubuntu, so no that command, sorry. Ok, alsa info works just as well, see wiki.ubuntu.com/Audio/AlsaInfo The codec is Conexant CX20671-21Z, id is '0x14f1506e'. I did some hacks, none works: * Switch the driver to latest one (embemed in linux 2.6.38-rc6) * Add an entry for 0x14f1506e, using patch_conexant_auto or patch_cxt5066 I just sent an entry for 506e upstream to alsa-devel. You might need a second quirk on top of that, just like I added for the Dell machines, see http://mailman.alsa-project.org/pipermail/alsa-devel/2011-February/037157.html BTW, I can see ports in alsamixer (for capture: mic1, mic2, mic3), which they can't be enumerated by PA? I can't tell without having alsa-info but you might to be helped by my input mixer rewrite, which I'm still trying to get tested and committed into PulseAudio. -- 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] Questions about no ports available to select.
On 2011-02-24 03:27, fykc...@gmail.com wrote: Hi David, Thanks for your work! You're welcome! 2011/2/23 David Henningssondavid.hennings...@canonical.com Ok, alsa info works just as well, see wiki.ubuntu.com/Audio/AlsaInfo Collected, see the attachment. I just sent an entry for 506e upstream to alsa-devel. You might need a second quirk on top of that, just like I added for the Dell machines, see http://mailman.alsa-project.org/pipermail/alsa-devel/2011-February/037157.html I tried it, but not work for me. I doubt my 506e is not the one you mentioned: 1. The vendor told me it's a Conexant 'CX20671-21Z', but yours is 'CX20590'. I have no idea of what the real name of the chip is - I picked 20590 because 506e is hexadecimal for 20590. 2. patch_conexant_auto works better than patch_cxt5066, the former doesn't break playback and bring PA sink ports, but still no source ports. From your alsa info I can note the following: 1) The node graph is just like the other 506e:s I've seen, and identical to the 5066 family. So the 506e patch is correct. 2) Given your pin configurations, you should add either options snd-hda-intel model=asus or options snd-hda-intel model=thinkpad to /etc/modprobe.d/alsa-base.conf. That is, in addition to the 506e patch I sent to alsa-devel. 3) For some reason, parsing has gone wrong on finding the PCI subsystem ID. To write a quirk that does model=thinkpad permanently, we'll need the PCI subsystem ID for the HDA Intel device. 4) Architecture: Mips64? Never seen HDA Intel connected to anything but amd64/i386, but I guess it's possible :-) Btw, feel free to move this thread to alsa-devel, as we're into ALSA level stuff rather than PulseAudio stuff. -- 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] Questions about no ports available to select.
On 2011-02-22 09:51, fykc...@gmail.com wrote: Hi all, I'm running pulseaudio 0.9.22 (from ubuntu natty, 0.9.22~0.9.21+stable-queue-32-g8478-0ubuntu21, see http://changelogs.ubuntu.com/changelogs/pool/main/p/pulseaudio/pulseaudio_0.9.22~0.9.21+stable-queue-32-g8478-0ubuntu21/changelog). I need to select a proper port to do record jobs, but find no ports(both source and sink in pavucontrol) available to select on my machine. The attachment is related log, any idea? Your log indicates your HDA codec is a Conexant ID 506e - the Conexant driver does not yet support this codec, so the driver falls back to a generic driver. I intend to make a new attempt later this week to add a quirk for that particular chip. If you, in the meantime, could point me to a bug in Launchpad (filed with the ubuntu-bug audio command), that would be helpful, as that would include valuable codec info. Thanks! -- 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] ANNOUNCE: Planning and Roadmap meeting: Thursday 24th Feb.
On 2011-02-22 23:03, Colin Guthrie wrote: 'Twas brillig, and Colin Guthrie at 22/02/11 10:37 did gyre and gimble: Hello, Now that we've got a few participants lined up, I thought I'd send another message. My previous time suggestion didn't fit with everyone, so the new best time is apparently 17:00 Thursday 24th Feb. If you want to particpate but this time doesn't suit you, please fill in the Doodle here that Arun started: http://www.doodle.com/ivx28di2kzztm2dt and reply to this thread. I will post an initial agenda later today for comment and further suggestions. I will also ping some people who may be interested but may not follow this list as closely as everyone else. I've posted an initial agenda up here: http://pulseaudio.org/wiki/Meetings/2011-02-24 There are a few topics there but some will be quite quick to discuss. Feel free to add items you feel are important and we can try and discuss them. We can try and do this in approx order of priority incase people have to leave before all topics are exhausted :D Status for jack detection might be worth discussing. This is becoming increasingly important, due to a lot of Nvidia HDMI audio cards that are having several outputs, and there is no way knowing which one is the correct one, before the monitor is actually plugged in. Also there seem to have been several implementations of this feature but none have been committed. Given Ubuntu time schedules, such a feature would require too much work to land in 11.04, so I don't plan to start working on it now, but I might spend some time implementing it for 11.10, i e around May - August. (No promises though - still too early to know what will happen and if other things will take more time than expected, etc.) -- 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] PA Roadmap Planning and LAC Conference
On 2011-02-17 00:54, Colin Guthrie wrote: Hi all, There have been a few discussions recently about getting a solid roadmap organised for the next medium term of PA development. While the stable-queue stuff has been bubbling along nicely enough, there are several new features in the 1.x master branch but no real timescales decided. There are quite a few willing people out there these days which is really encouraging, but we need to get a solid focus on when to expect releases and what we hope to achieve in each one. This email is the start of that process. This is a great initiative, thanks! In addition, there is the LAC conference[1] in Dublin (or just outside) in May and there is already plans for quite a few PA developers and interested parties attending. I will book my flights very soon, but if there are several of us going, then I wonder if it would make sense to try and have a sprint day before the conference (or after) to see if we can all sit down in once place and concentrate on stuff for a little while. Being in one pace would probably help a lot with certain discussions and really help progress. So this email is really about two things: 1. Planning a time for an IRC meeting on the near term Road Map. 2. Discussions if a sprint day at LAC is possible (so we can book flights. With regards to IRC meeting, I propose initially that we do this next week sometime (the sooner the better). For the sake of argument, I'll pick a time: 11am UTC Thursday 24th. Other timing suggestions welcome. I'd expect it to take at least 1h but probably less than 2h and it would be good if people involved could be fairly focused during the meeting window. I'll prepare an agenda and ensure that notes/logs are taken (with a meetbot) and made available afterwords. We will likely use a new IRC channel for this but anyone who wants to sit in, lurk or actively particpate would be most welcome. Q: Is this time suitable for everyone (Lennart in particular)? Works for me. With regards to LAC, David has already indicated he'll have to leave on the Sunday (after the conf which is on Fri/Sat), so if no-one has any objections, I'll propose that we have a Sprint day on Thursday 5th May (ideally so people can arrive on Wed evening or early Thursday so we get the full day). How would that fit for everyone? I've no idea about space/location, but I'm sure something can be arranged, even if it's just in the corner of a pub! Agreed. Could also be worth checking with the LAC organisers if they could spare a room for us on Thursday. Perhaps this can just be incorporated into the Fri/Sat programme anyway and a separate day is not needed? Having not been before, I'm not sure how practical the conf is and whether the extra day would be needed or beneficial, but my general thoughts would be more time = more code, so an extra day could still be nice! I would prefer a separate day. This is because I don't want to miss the rest of the conference. -- 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] New feature in the works: volume sharing
On 2011-02-14 12:45, Colin Guthrie wrote: 'Twas brillig, and Tanu Kaskinen at 14/02/11 11:19 did gyre and gimble: On Sun, 2011-02-13 at 22:05 +0200, Colin Guthrie wrote: With this push based approach, you do loose some individual granularity, but the net volume of the underlying h/w should be the same as your approach. What granularity would I lose? I think your suggested logic would be quite equivalent to the one that I originally proposed. The concern I have with the approach outlined, is that it adds complexity to the core and I'm not 100% sure how far the chain can go (e.g. can you have a filter-sink1-filter-sink2-filter-sink3-hw-sink pipeline? - with a push model this is possible). It's possible with the pull model too - the filter sinks are always traversed recursively. About complexity - I haven't done a thorough analysis of your suggestion, but I would guess that it would be a little bit simpler. There would still be a significant amount of added complexity in the core, though. I'll finish the patch using the original logic first, and if you want, I can probably do another version to see how much the push model will differ. I don't really want to create extra work for you, I'm just genuinely unsure which would be considered a cleaner approach (or even if it really matters at all!!) Other opinions welcome :) I have a question: how about the volume store/restore module? Will it store and restore the outermost sink's volume, the innermost one, or both? Another thing is the pick-up of volume/mute changes in the driver - at least that's done on the ALSA side. Will that then be pushed through in the other direction somehow, or...? Just trying to make sure you haven't missed anything :-) -- 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] Improvement suggestion
On 2011-02-12 15:07, Olof wrote: Hi! Hi Olof! This might be the wrong place but I didn't find anything better. I'm using ubuntu 11.04 with pulseaudio 0.9.21-63-gd3efa-dirty. This does not make sense - Ubuntu 11.04 (as in Natty, the development version) is having 0.9.22 based Pulseaudio. I had severe problems getting a monitor to work because I didn't understand that the button with a loudspeaker on the input tab in the volume control was something one could click on. It looks exactly the same whether the monitor is muted or not. I think there is room for improvement here, some kind of indication that the current state is muted and one can fix it by clicking here would be appreciated! Thanks! Are you talking about pavucontrol? I agree that the buttons could be clearer. -- 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] State of various rate adjustment patches
On 2011-02-09 17:07, Maarten Bosmans wrote: As I said before, the last commit [72b90ea8ac53e23862284991a2ce355de250f585] is really beyond my understanding of rewinds and would definately not be appropriate for stable-queue without further review. Also, it has not been tested in combination with David's rewind patches, so that needs to be done too. From what I can tell, the change seems to be copy-pasted from protocol-native.c, and so it's probably correct. My rewind patches shouldn't change that either for better or for worse. That said, of course testing wouldn't hurt :-) -- 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] Make discoverable PA network sound devices available locally results in huge network traffic
On 2011-02-09 17:13, Maarten Bosmans wrote: 2011/1/26 Colin Guthriegm...@colin.guthr.ie: 'Twas brillig, and Maarten Bosmans at 26/01/11 10:49 did gyre and gimble: 2011/1/22 Colin Guthriegm...@colin.guthr.ie: 'Twas brillig, and Maarten Bosmans at 22/01/11 10:11 did gyre and gimble: I actually wonder if this is the cause of the vumeters sometimes not initialising properly at times... (I presume other people see this occasionally? It's never quite bothered me enough to look into it properly!) Well, I was pleasantly surprised to see that pavucontrol from git master worked a lot better than the version packaged on Ubuntu (0.9.9). I'll use the newest version for a while and look out for little problems like you described. Yeah I've been meaning to push out a new release at some point (Lennart asked me a while back to handle that but I said I'd happily hack on it and let him do the releases, but I'll probably just take over the releases now :D) If you'd care to add my patch and make a release, I'll poke whoever is the maintainer of pavucontrol to include a newer version. That would probably be Sjoerd Simmons sjo...@debian.org. Now that Debian 6.0 is out I guess getting stuff in that way will be easier, hopefully. Btw, we all seem to be busy with our own stuff only, but we all would like others to test the stuff we do, so do you want to make a deal? :-) I'll test some of your patches (tell me which ones) if you test my pulse-mixer patches. -- 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] [PATCH] Pulseaudio input mixer rewrite
1) Bump! 2) The kernel patches mentioned below are all in the 2.6.38 kernel. On 2011-01-19 17:19, David Henningsson wrote: On 2011-01-19 16:59, David Henningsson wrote: Yeah, I guess it's time. Let me know if you want six emails instead of one. Over the past few weeks - although there always seems to be something else you have to fix first - I've been working on fixing the long-standing issues with the pulseaudio mixer paths not working correctly on the input side: basically it isn't showing helpful enough names (e g Microphone 1 and Microphone 2 instead of Front Microphone and Rear Microphone), and not always controlling the right sliders underneath. I have tested it on the stuff I have here and it seems to work well enough. For Ubuntu users, easy testing is here: https://launchpad.net/~diwic/+archive/pulse-mixer Realtek HDA codecs might need two recent ALSA commits that rename Mic Boost to Mic Boost Volume, and to change an index error that made PA ignore the control. They are both in queue for 2.6.38. I've also made some changes in the kernel to clear up the namespace (i e change some of the more crazy names to standard names) recently that might be interesting. For reference, here are the patches you want for Realtek: ALSA: HDA: Fix volume control indices for Mics (Realtek) - http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5322bf2790fb91328aac1783bb1963ea3a172bcf ALSA: HDA: Rename Mic Boost to Mic Boost Volume - http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5f99f86a801f937ed51deedc36ad4efc47d95cdd And for some various renaming: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=10528020d7323778b60c2de04754a2615a88d002 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8607f7c4245bc1737989d908e9c5adbfe4f5d06d http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=28c4edb71d21623f1e47422194d865d2b6712fd4 -- 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] Fighting rewinds / pulseaudio crash - update
On 2011-01-31 12:41, Colin Guthrie wrote: 'Twas brillig, and David Henningsson at 31/01/11 10:46 did gyre and gimble: On 2011-01-31 10:41, Colin Guthrie wrote: Thanks for the update David :) You're welcome :-) PulseAudio #1 and #2: I believe these should be applied to PulseAudio upstream. OK, I think you've given it sufficient testing and exposer to confirm this. Can I just ask if these are safe if the corresponding gst fixes are not committed? (i.e. will GST generally bork or should it cope as well as currently without it's patches?) Both are optimisations - gst patch only will be better than no patch at all, and PA patch only will be better than no patch at all. Most people will see it solved by either patch, but I guess that there are machines so slow that you'll need both. No worries, just wanted to make sure that it wasn't a paired updated - e.g. the PA commits *required* the GST ones (I figured it was very unlikely but with the Skype issue on the third patch, I figured I'd be safer ask!) Also, master only or master+s-q (I'm personally favouring the latter). Me too. OK, applied to my tree now with a tiny modification due to Lennart's rate limit patch on s-q which I've now merged to master (with updates for additional calls). Will push once I've done a few more bits and bobs. Thanks :-) This, and that Takashi agreed to take my ALSA patch in 2.6.38 as well (totally unrelated), this might actually turn out to be a really good day! :-) -- 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
[pulseaudio-discuss] [PATCH] Pulseaudio input mixer rewrite
Yeah, I guess it's time. Let me know if you want six emails instead of one.
Over the past few weeks - although there always seems to be something
else you have to fix first - I've been working on fixing the
long-standing issues with the pulseaudio mixer paths not working
correctly on the input side: basically it isn't showing helpful enough
names (e g Microphone 1 and Microphone 2 instead of Front
Microphone and Rear Microphone), and not always controlling the right
sliders underneath.
I have tested it on the stuff I have here and it seems to work well
enough. For Ubuntu users, easy testing is here:
https://launchpad.net/~diwic/+archive/pulse-mixer
Realtek HDA codecs might need two recent ALSA commits that rename Mic
Boost to Mic Boost Volume, and to change an index error that made PA
ignore the control. They are both in queue for 2.6.38. I've also made
some changes in the kernel to clear up the namespace (i e change some of
the more crazy names to standard names) recently that might be interesting.
As for where this is going (master, stable-queue, or /dev/null?) -
speaking from Ubuntu's standpoint I'd strongly prefer stable-queue,
because I want this in Ubuntu 11.04, which is based on stable-queue. Me
being biassed, It'll be up to the rest of you (Colin etc) to make the
decision given that there is somewhat of a regression risk, at least for
unusual hardware.
// David
From 729223d4c2c8e56e1e4bf838ee9aa11d36f2d90a Mon Sep 17 00:00:00 2001
From: David Henningsson david.hennings...@canonical.com
Date: Mon, 20 Dec 2010 11:13:37 +0100
Subject: [PATCH 1/6] alsa-mixer: Add a few well-known descriptions
Add front mic, rear mic, and docking line-in. These are likely to be
present on modern hda chips, for reference see
linux-2.6/sound/pci/hda/hda_codec.c:hda_get_input_pin_label
Signed-off-by: David Henningsson david.hennings...@canonical.com
---
src/modules/alsa/alsa-mixer.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/src/modules/alsa/alsa-mixer.c b/src/modules/alsa/alsa-mixer.c
index 1ede8cf..eb50ae2 100644
--- a/src/modules/alsa/alsa-mixer.c
+++ b/src/modules/alsa/alsa-mixer.c
@@ -1701,8 +1701,11 @@ static int option_verify(pa_alsa_option *o) {
{ input, N_(Input) },
{ input-docking, N_(Docking Station Input) },
{ input-docking-microphone, N_(Docking Station Microphone) },
+{ input-docking-linein, N_(Docking Station Line-In) },
{ input-linein, N_(Line-In) },
{ input-microphone, N_(Microphone) },
+{ input-microphone-front,N_(Front Microphone) },
+{ input-microphone-rear, N_(Rear Microphone) },
{ input-microphone-external, N_(External Microphone) },
{ input-microphone-internal, N_(Internal Microphone) },
{ input-radio, N_(Radio) },
@@ -1776,6 +1779,10 @@ static int path_verify(pa_alsa_path *p) {
static const struct description_map well_known_descriptions[] = {
{ analog-input, N_(Analog Input) },
{ analog-input-microphone,N_(Analog Microphone) },
+{ analog-input-microphone-front,N_(Front Microphone) },
+{ analog-input-microphone-rear, N_(Rear Microphone) },
+{ analog-input-microphone-dock, N_(Docking Station Microphone) },
+{ analog-input-microphone-internal, N_(Internal Microphone) },
{ analog-input-linein,N_(Analog Line-In) },
{ analog-input-radio, N_(Analog Radio) },
{ analog-input-video, N_(Analog Video) },
--
1.7.1
From ae83e51c82a747332494bf10c245281e49343fe3 Mon Sep 17 00:00:00 2001
From: David Henningsson david.hennings...@canonical.com
Date: Mon, 20 Dec 2010 12:29:27 +0100
Subject: [PATCH 2/6] alsa-mixer: add required-any and required-* for enum options
Now you can add required-any to elements in a path and the path
will be valid as long as at least one of the elements are present.
Also you can have required, required-any and required-absent in
element options, causing a path to be unsupported if an option is
(not) present (simplified example: to skip line in path if
Capture source doesn't have a Line In option).
Signed-off-by: David Henningsson david.hennings...@canonical.com
---
src/modules/alsa/alsa-mixer.c | 90 +---
src/modules/alsa/alsa-mixer.h |8 ++
.../alsa/mixer/paths/analog-output.conf.common |5 +
3 files changed, 91 insertions(+), 12 deletions(-)
diff --git a/src/modules/alsa/alsa-mixer.c b/src/modules/alsa/alsa-mixer.c
index eb50ae2..2c47319 100644
--- a/src/modules/alsa/alsa-mixer.c
+++ b/src/modules/alsa/alsa-mixer.c
@@ -1018,6 +1018,38 @@ static int check_required(pa_alsa_element *e, snd_mixer_elem_t *me) {
if (e-required_absent == PA_ALSA_REQUIRED_ANY (has_switch || has_volume || has_enumeration))
return -1;
+if (e
Re: [pulseaudio-discuss] [PATCH] Pulseaudio input mixer rewrite
On 2011-01-19 16:59, David Henningsson wrote: Yeah, I guess it's time. Let me know if you want six emails instead of one. Over the past few weeks - although there always seems to be something else you have to fix first - I've been working on fixing the long-standing issues with the pulseaudio mixer paths not working correctly on the input side: basically it isn't showing helpful enough names (e g Microphone 1 and Microphone 2 instead of Front Microphone and Rear Microphone), and not always controlling the right sliders underneath. I have tested it on the stuff I have here and it seems to work well enough. For Ubuntu users, easy testing is here: https://launchpad.net/~diwic/+archive/pulse-mixer Realtek HDA codecs might need two recent ALSA commits that rename Mic Boost to Mic Boost Volume, and to change an index error that made PA ignore the control. They are both in queue for 2.6.38. I've also made some changes in the kernel to clear up the namespace (i e change some of the more crazy names to standard names) recently that might be interesting. For reference, here are the patches you want for Realtek: ALSA: HDA: Fix volume control indices for Mics (Realtek) - http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5322bf2790fb91328aac1783bb1963ea3a172bcf ALSA: HDA: Rename Mic Boost to Mic Boost Volume - http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5f99f86a801f937ed51deedc36ad4efc47d95cdd And for some various renaming: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=10528020d7323778b60c2de04754a2615a88d002 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8607f7c4245bc1737989d908e9c5adbfe4f5d06d http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=28c4edb71d21623f1e47422194d865d2b6712fd4 -- 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] USB audio devices muted at non-zero volume
On 2011-01-06 15:31, Colin Guthrie wrote: Hi Marius 'Twas brillig, and Marius Bjørnstad at 06/01/11 12:39 did gyre and gimble: The devices below are muted at a volume greater than 0. This causes a significant portion of the volume in Pulseaudio to be equal to zero (muted). 0d8c:000e C-Media Electronics, Inc. Audio Adapter (Planet UP-100, Genius G-Talk) 0b05:1743 ASUSTek Computer, Inc. Xonar U1 Audio Station The asus card is muted at volume 1, the Plantronics ( C-Media ) is muted at volume 2. Both volumes are in alsamixer. Is there any way to fix this in Pulseaudio (some kind of quirks database, for example)? This isn't an uncommon thing, but it's getting better. The problem is very likely that the device is incorrectly reporting it's dB range and thus PA cannot control it correctly. It's possible to add quirks in the driver to correct the range. http://www.pulseaudio.org/wiki/BadDecibel http://mailman.alsa-project.org/pipermail/alsa-devel/2010-February/025213.html David Henningsson from Canonical also wrote a similar tool: http://thread.gmane.org/gmane.comp.audio.pulseaudio.general/7542 I'm not sure off hand what the latest version of that tool is or if there is a proper webpage for it. David, can you elaborate? No, there isn't one. Here's the latest version: https://launchpad.net/~diwic/+archive/maverick (for Ubuntu 10.10) https://launchpad.net/~diwic/+archive/ppa (for Ubuntu 10.04) https://launchpad.net/~diwic/+archive/ppa/+files/alsamixertest_48.11.tar.gz (for other distros) It currently tests playback only. Before it makes sense to test recording as well, we'll have to fix up the input mixer paths in PulseAudio. I'm currently working on that, and making good progress. -- 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] [PATCH] Implement Fortemedia SMA processing.
On 2011-01-06 01:32, Alban Browaeys wrote:
From 853a4d96bf2624ef30f86cf4819382949d039c87 Mon Sep 17 00:00:00 2001
From: Alban Browaeyspra...@yahoo.com
Date: Wed, 5 Jan 2011 17:13:04 +0100
Subject: [PATCH] Implement Fortemedia SMA processing.
Those small array microphones returns two channels of opposite
phase thus the default remap in pulseaudio doing the sum output
silence.
Sounds very useful, but...
+void pa_fmaudiosma_run(pa_fmaudiosma *fs, const uint8_t *rec, uint8_t *out,
int n) {
+unsigned i;
+
+float *d, *s;
+int n_frames = n / (sizeof(float) * 2);
+memset(out, 0, n_frames * sizeof (float) * 2);
+
+d = (float *)out;
+s = (float *)rec;
+for (i = n_frames; i 0; i--, s += 2, d += 2)
+ d[0] = d[1] = s[0] - (s[0] + s[1]);
s[0] - (s[0] + s[1]) can be simplified to -s[1], unless my junior
high math fails me completely. Are you sure you don't mean s[0] - s[1]?
--
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] What to do with the Smart 5.1 mixer element (VIA VT1708S)
On 2011-01-03 13:01, Colin Guthrie wrote: As detailed here: https://qa.mandriva.com/show_bug.cgi?id=60467 Should be add this to the alsa init db or patch our mixer profiles? Well, wouldn't the most logical thing be to enable Smart 5.1 if we have a surround profile, and disable it if we have line or mic input? That is, assuming that the stuff actually works - I'm still trying to understand the Independent HP/Jack detect stuff (another strange thing in the VIA codec driver), what's causing headphones on Asus K50IJ/K60I not to work, and why toggling the switch crashes alsamixer... :-( I was hoping to be able to fix some of that by the time of merge window for 2.6.38, but I'm not sure I have the time/priority to do so. -- 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] *reminder* Re: [PATCH 0/3] Fighting rewinds
On 2010-12-17 17:39, Marius Bjørnstad wrote: On 15/12/10 08:41, David Henningsson wrote: For users running Ubuntu Maverick, there is a ppa for easy testing here: https://launchpad.net/~diwic/+archive/fighting-rewinds It also includes two fixes on the gstreamer side. Hi, I installed the PPA, and the audio in Skype stopped working. There is no error messages, but I hear no notification sounds and no audio during calls. Sometimes, apparently at random times, I hear one of the notification sounds (login, end call). I must have triggered the playback of the sounds at some time before. In other programs, the sound works fine. Please say if there is any debug info that i can provide. Thanks for testing. Would it be possible for you two who had regressions to determine if it is patch 1, 1+2, or 3 that's causing the regression? Thanks in advance! -- 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
[pulseaudio-discuss] *reminder* Re: [PATCH 0/3] Fighting rewinds
On 2010-12-09 14:54, David Henningsson wrote: As some of you have seen on IRC, I spent the some of the last week fighting rewinds. An never-ending stream of rewinds seems to be one of the most common reasons PulseAudio crashes or produces crackling/stuttering output, so there is a strong incentive to fix it. However, the problem is quite complex and there does not seem to be one perfect fix, it's more of an optimisation problem. GStreamer in particular sends out many small data packages, and PulseAudio does not handle that very well. When the sink-input buffer is empty, going from there to a full buffer is an uphill battle in terms of CPU power, as PulseAudio will try to rewind (at RT priority!) and mix the new data into it; all with the very best intent, but the end result of taking CPU power away from the client. GStreamer has at least two problems: * It starts/uncorks the stream when the buffer is empty (this might have been fixed by Wim a day or two ago) * It sends out very small packages (c:a 1 - 4K). Here are three patches trying to help out on the PA side. * The first one is a relatively simple optimisation than can cut the rewinds in half by allowing both a seek and a post to be merged into one rewind. * The second one builds on the first, and adds the possibility for several data packages to share a rewind by checking if there are more data packets in queue before doing a rewind. * The third makes sure that after an underrun, there is a little headroom before asking for a rewind. Hopefully this will improve the situation for at least a few users. The idea is to let you do initial comment and review, then make a package and ask some Ubuntu users to test it. After that I'll report back and we can consider inclusion into stable-queue. I never saw any feedback on the patches, is this because of lack of time, interest (i e you're not affected by the problem anyway), or knowledge (i e you don't know how the stuff works), or something else? For users running Ubuntu Maverick, there is a ppa for easy testing here: https://launchpad.net/~diwic/+archive/fighting-rewinds It also includes two fixes on the gstreamer side. -- 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
[pulseaudio-discuss] [PATCH 3/3] Fighting rewinds: Make sure there is some headroom after an underrun
If the amount of data in the implementor buffer is very tiny,
i e even less than what we will likely be asked for, don't ask
for a rewind as that would lead to another underrun.
--
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic
From 3c0bf348c3395b3cff0d77fd52a2e1e725c6e4cd Mon Sep 17 00:00:00 2001
From: David Henningsson david.hennings...@canonical.com
Date: Thu, 9 Dec 2010 14:25:58 +0100
Subject: [PATCH 3/3] Fighting rewinds: Make sure there is some headroom after an underrun
If the amount of data in the implementor buffer is very tiny,
i e even less than what we will likely be asked for, don't ask
for a rewind as that would lead to another underrun.
Signed-off-by: David Henningsson david.hennings...@canonical.com
---
src/pulsecore/protocol-native.c | 15 +--
1 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/src/pulsecore/protocol-native.c b/src/pulsecore/protocol-native.c
index 5dab80e..378a401 100644
--- a/src/pulsecore/protocol-native.c
+++ b/src/pulsecore/protocol-native.c
@@ -1321,9 +1321,18 @@ static void handle_seek(playback_stream *s, int64_t indexw) {
/* pa_log(%lu vs. %lu, (unsigned long) pa_memblockq_get_length(s-memblockq), (unsigned long) pa_memblockq_get_prebuf(s-memblockq)); */
if (pa_memblockq_is_readable(s-memblockq)) {
+if (s-sink_input-sink) {
+pa_usec_t usec = pa_sink_get_latency_within_thread(s-sink_input-sink);
+int latency = pa_usec_to_bytes(usec, s-sink_input-sample_spec);
+if (latency pa_memblockq_get_length(s-memblockq)) {
+pa_log_debug(Skipping rewind, need at least %d bytes., latency);
+playback_stream_request_bytes(s);
+return;
+}
+}
-/* We just ended an underrun, let's ask the sink
- * for a complete rewind rewrite */
+/* We ended an underrun and got some head start,
+ * let's ask the sink for a complete rewind rewrite */
pa_log_debug(Requesting rewind due to end of underrun.);
pa_sink_input_request_rewind(s-sink_input,
@@ -1524,6 +1533,8 @@ static int sink_input_pop_cb(pa_sink_input *i, size_t nbytes, pa_memchunk *chunk
s-is_underrun = TRUE;
playback_stream_request_bytes(s);
+/* Don't return a block here - it confuses the underrun handling in sink-input later */
+return -1;
}
/* This call will not fail with prebuf=0, hence we check for
--
1.7.1
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Mic input volume controls
On 2010-12-04 19:09, Colin Guthrie wrote: 'Twas brillig, and David Henningsson at 02/12/10 10:38 did gyre and gimble: On 2010-12-01 16:09, Colin Guthrie wrote: 'Twas brillig, and David Henningsson at 01/12/10 13:55 did gyre and gimble: Hi folks, The way we control mic input is quite broken. I've tested here with both IDT codecs and Realtek codecs (the two most common HDA Codecs AFAIK) and as far as I see they're both broken in the same ways. Let's assume that we have an internal mic and an external mic jack, with autoswitching in the kernel. We have a Mic Boost affecting the external mic jack, a Front Mic Boost affecting internal mic, and a Capture control affecting both. Mic Boost and Front Mic Boost go from 0 to 60 dB in 20 dB steps, and Capture goes from 0 to 22.5 dB in 1.5 dB steps. 1) The first problem is PA is unable to combine both of them correctly: for the first 0 to 22.5 dB, PA moves the Capture control only. After that say at 25 dB, Mic Boost moves to +20 dB, keeping Capture at 22.5 dB, then using softvol to compensate, instead of lowering Capture. I've been suggested that changing the order of Mic Boost and Capture improves this situation, so we should probably do that. Any objections? With the direction argument passed to the relevant alsa calls as we currently have, swapping them around should indeed help here yes. No objection in principle for me. I guess we'll just statically swap them around for now? In theory, I guess the order of the controlled element pipeline could be dynamically adjusted so that biggest steps happen first... but this approach would possibly introduce unwanted side effets. Hmm. I remember Lennart's original approach would have been to maximize signal quality (i e, move Master and let PCM stay at 0 dB). Moving this analogy to the input case, what would be the highest quality for 20 dB - having Mic Boost at 20 dB and Capture at 0 dB, or Mic Boost at 0 dB and Capture at 20 dB? I would agree that using the highest quality pipeline is probably the best approach, but I'm afraid I also have no idea how to determine which approach is higher quality! My logic of putting the biggest steps first was really just to maximise using alsa controls rather than falling back to our own adjustments in software. This just seemed sensible but there could very well be quality arguments against it (I wouldn't want my PCM to be favoured over my Master for playback for example as the former is softvol) Let's play with the idea that we added a configurable Direction key to these profiles that controlled whether we moved up or down to the nearest step. Wouldn't that help? Then we could have Mic Boost first in chain, then set it to move down rather than up. Or maybe that we should instead say that if we're above 0 dB, we move down, and if we're below 0 dB, we move up? Would that make sense? I'm not really sure here. A specific direction key may complicate what is already a rather complicated thing, so if we can possibly do things sensibly without it, then I'd suggest that would be more attractive (if it works reliably enough). We want to maximise quality while avoiding digital distortion, that's basically the problem in a nutshell. We're assuming (sometimes incorrectly; but that's our best guess) that this golden spot will be achieved with all sliders at 0 dB. I think my approach makes sense, unless I'm missing something: If we're aiming for something above 0 dB, let's round down to make sure we avoid distortion, and if we're below 0 dB, let's round up to make sure we get maximum quality. And then we always start with the control that's closest to the physical hardware and work our way in. What's in and out here; that's currently determined by the order in which PulseAudio reads them in, right? That complicates matters a little given the include file structure and so I'm thinking maybe we should add a extremity=number key to the config file? (This is unrelated to the direction key suggested previously.) We would then start with the one having the highest extremity score. Otherwise we would get in trouble if we have a profile with a volume control B (with extremity=2), which then includes a file with both control A (with extremity=1) and control C (with extremity=3) in the same include file. I think that would actually make things clearer. What do you think? 2) The harder problem is that PulseAudio does not know whether to control Mic Boost or Front Mic Boost, since it doesn't know what path is active at the moment. While we really need some kind of module, and appropriate kernel support, the question is what we do before that becomes sufficiently available. The next best solution, would probably be to have different profiles and manual autoswitching. While I yet have to look into the details, I guess we'll have to add different profiles for Mic, Front Mic, Rear Mic and so on, instead of having them in the same file as we have today. Any thoughts? I
[pulseaudio-discuss] [PATCH] JACK: Add module-jackdbus-detect
Over the past few days I've been making a new PulseAudio module that detects the presence of JACK server, and adds a sources and a sink when JACK is started. Here are the notes: * This version uses JACK's dbus interface to detect server being started or stopped, i e /usr/bin/jackdbus instead of /usr/bin/jackd. If you use qjackctl to control the server, make sure that you check the checkbox Enable D-Bus interface under Setup - Misc. * It is deliberately named module-jackdbus-detect instead of module-jack-detect, both to emphasize the above, and to avoid name clashes with an imaginary (?) future module detecting whether headphones are plugged in or not. * The patch is against stable-queue. * It is probably ready for merging into the next version of PA. I'm saying probably, since during testing yesterday, I sometimes got segfaults. However, I believe these are related to something happening inside libjack when the server shuts down; since I can trigger the same segfaults even without my new module involved. That said; it takes fewer strokes with the module enabled, as you can just press start and stop in qjackctl until it happens... * A question is about the default; patch 2 here adds it to default.pa. Should connect default to true or false in such a scenario? I think it depends on whether we're aiming for just showing the user the possibility (connect=false), or if we're aiming for a just-works experience (connect=true), which might upset a few people who don't want it to work that way...I've gone with connect=true as the default to mimic the behaviour of module-jack-sink and module-jack-source. -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic From d111edff2667dcdaad69a0d32bee8358966e5f42 Mon Sep 17 00:00:00 2001 From: David Henningsson david.hennings...@canonical.com Date: Tue, 30 Nov 2010 04:59:27 +0100 Subject: [PATCH 1/2] JACK: Add module-jackdbus-detect Signed-off-by: David Henningsson david.hennings...@canonical.com --- src/Makefile.am | 12 ++ src/modules/jack/module-jackdbus-detect.c | 304 + 2 files changed, 316 insertions(+), 0 deletions(-) create mode 100644 src/modules/jack/module-jackdbus-detect.c diff --git a/src/Makefile.am b/src/Makefile.am index 164faa6..799ab8d 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -1124,6 +1124,12 @@ if HAVE_JACK modlibexec_LTLIBRARIES += \ module-jack-sink.la \ module-jack-source.la + +if HAVE_DBUS +modlibexec_LTLIBRARIES += \ + module-jackdbus-detect.la +endif + endif if HAVE_GCONF @@ -1228,6 +1234,7 @@ SYMDEF_FILES = \ modules/module-detect-symdef.h \ modules/rtp/module-rtp-send-symdef.h \ modules/rtp/module-rtp-recv-symdef.h \ + modules/jack/module-jackdbus-detect-symdef.h \ modules/jack/module-jack-sink-symdef.h \ modules/jack/module-jack-source-symdef.h \ modules/module-volume-restore-symdef.h \ @@ -1607,6 +1614,11 @@ module_rtp_recv_la_CFLAGS = $(AM_CFLAGS) # JACK +module_jackdbus_detect_la_SOURCES = modules/jack/module-jackdbus-detect.c +module_jackdbus_detect_la_LDFLAGS = $(MODULE_LDFLAGS) +module_jackdbus_detect_la_LIBADD = $(AM_LIBADD) $(DBUS_LIBS) libpulseco...@pa_majorminormicro@.la $(JACK_LIBS) libpulsecomm...@pa_majorminormicro@.la libpulse.la +module_jackdbus_detect_la_CFLAGS = $(AM_CFLAGS) $(DBUS_CFLAGS) $(JACK_CFLAGS) + module_jack_sink_la_SOURCES = modules/jack/module-jack-sink.c module_jack_sink_la_LDFLAGS = $(MODULE_LDFLAGS) module_jack_sink_la_LIBADD = $(AM_LIBADD) libpulseco...@pa_majorminormicro@.la $(JACK_LIBS) libpulsecomm...@pa_majorminormicro@.la libpulse.la diff --git a/src/modules/jack/module-jackdbus-detect.c b/src/modules/jack/module-jackdbus-detect.c new file mode 100644 index 000..f635b23 --- /dev/null +++ b/src/modules/jack/module-jackdbus-detect.c @@ -0,0 +1,304 @@ +/*** + This file is part of PulseAudio. + + Written by David Henningsson david.hennings...@canonical.com + Copyright 2010 Canonical Ltd. + + Some code taken from other parts of PulseAudio, these are + Copyright 2006-2009 Lennart Poettering + + PulseAudio is free software; you can redistribute it and/or modify + it under the terms of the GNU Lesser General Public License as published + by the Free Software Foundation; either version 2.1 of the License, + or (at your option) any later version. + + PulseAudio is distributed in the hope that it will be useful, but + WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + General Public License for more details. + + You should have received a copy of the GNU Lesser General Public License + along with PulseAudio; if not, write to the Free Software + Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 + USA. +***/ + +#ifdef HAVE_CONFIG_H +#include config.h +#endif + +#include pulsecore/log.h +#include pulsecore/modargs.h +#include pulsecore/core-util.h +#include
Re: [pulseaudio-discuss] [PATCH] JACK: Add module-jackdbus-detect
On 2010-12-03 11:35, Colin Guthrie wrote: Hiya Seems like a good patch at first glance. Thanks! :-) One minor question that I really don't know the answer to right now, but firgured it's worth asking. This approach seems totally separate from the device reservation protocol that works between Jack and PA to do graceful handover. Is there any chance of races here between the two different IPCs? I don't think so (i'd expect Jack to ensure it gets the device first before it reports that it isStarted()). I'd say they are unrelated. The device handover, as you say, might happen before JACK is fully started. Also; JACK controlling ALSA is not all use cases, JACK can also control firewire sound cards (and it has network and oss drivers as well). Also IIRC, there is no automatic stream moving/rescuing when device reservation happens, so existing streams will not move, you'll still have to manually switch to the JACK sink in kde/gnome/pavu-control. I suspect that this is actually needed as if we try to load the jack-sink's immediately when we hand over the device control to jack, then jack is likely not ready yet (I think Lennart mentioned this in the past, and thus makes me thing that speaking to jack directly (as you do) is the only way to make this work correctly) 'Twas brillig, and David Henningsson at 03/12/10 08:29 did gyre and gimble: * A question is about the default; patch 2 here adds it to default.pa. Should connect default to true or false in such a scenario? I think it depends on whether we're aiming for just showing the user the possibility (connect=false), or if we're aiming for a just-works experience (connect=true), which might upset a few people who don't want it to work that way...I've gone with connect=true as the default to mimic the behaviour of module-jack-sink and module-jack-source. I think it's probably OK to go into default.pa, but it could also be an option in paprefs too. e.g. a ticky box for: [ ] Automatically redirect audio through Jack if it is started or similar. WDYT is best? Perhaps I need to explain a little further - there is a routing patchbay inside the JACK server; connect=true means that when a module-jack-sink is started, it will connect the jack-sink (which is an input seen from JACK) to the system's sound card output. If connect=false, it will just show up as an unconnected sink, making it easy for people who want to connect that sink to the sound card, run it through a vocoder [1], record it into Ardour, or anything else. Perhaps we should go and ask the Ubuntu Studio and/or Planet CCRMA folks and see if they have an opinion? Leaving them unconnected would be a less invasive approach. -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic [1] Admit you always wanted your system sounds vocoded! ;-) ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Mic input volume controls
On 2010-12-01 16:09, Colin Guthrie wrote: 'Twas brillig, and David Henningsson at 01/12/10 13:55 did gyre and gimble: Hi folks, The way we control mic input is quite broken. I've tested here with both IDT codecs and Realtek codecs (the two most common HDA Codecs AFAIK) and as far as I see they're both broken in the same ways. Let's assume that we have an internal mic and an external mic jack, with autoswitching in the kernel. We have a Mic Boost affecting the external mic jack, a Front Mic Boost affecting internal mic, and a Capture control affecting both. Mic Boost and Front Mic Boost go from 0 to 60 dB in 20 dB steps, and Capture goes from 0 to 22.5 dB in 1.5 dB steps. 1) The first problem is PA is unable to combine both of them correctly: for the first 0 to 22.5 dB, PA moves the Capture control only. After that say at 25 dB, Mic Boost moves to +20 dB, keeping Capture at 22.5 dB, then using softvol to compensate, instead of lowering Capture. I've been suggested that changing the order of Mic Boost and Capture improves this situation, so we should probably do that. Any objections? With the direction argument passed to the relevant alsa calls as we currently have, swapping them around should indeed help here yes. No objection in principle for me. I guess we'll just statically swap them around for now? In theory, I guess the order of the controlled element pipeline could be dynamically adjusted so that biggest steps happen first... but this approach would possibly introduce unwanted side effets. Hmm. I remember Lennart's original approach would have been to maximize signal quality (i e, move Master and let PCM stay at 0 dB). Moving this analogy to the input case, what would be the highest quality for 20 dB - having Mic Boost at 20 dB and Capture at 0 dB, or Mic Boost at 0 dB and Capture at 20 dB? To be honest, I'm not sure, but in theory I assume Mic Boost should be at 20 dB and Capture at 0 dB because the signal path between Mic Boost and Capture would be stronger. Let's play with the idea that we added a configurable Direction key to these profiles that controlled whether we moved up or down to the nearest step. Wouldn't that help? Then we could have Mic Boost first in chain, then set it to move down rather than up. Or maybe that we should instead say that if we're above 0 dB, we move down, and if we're below 0 dB, we move up? Would that make sense? 2) The harder problem is that PulseAudio does not know whether to control Mic Boost or Front Mic Boost, since it doesn't know what path is active at the moment. While we really need some kind of module, and appropriate kernel support, the question is what we do before that becomes sufficiently available. The next best solution, would probably be to have different profiles and manual autoswitching. While I yet have to look into the details, I guess we'll have to add different profiles for Mic, Front Mic, Rear Mic and so on, instead of having them in the same file as we have today. Any thoughts? I guess splitting them out makes sense so as to keep the pipeline for each clean. Would you still envisage keeping each mic as a separate port? Hmm, what does port mean in this context? Since we might have to control different pipelines, I don't see how we can have it in the same profile. (I guess the only other option would be to check if both mics could be opened at the same time in the profile probing to allow for two alsa-sources to be loaded at the same time. But that's likely going to lead to a lot of other problems, Agreed; let's avoid more than one alsa-source at this point even if it's possible for some codecs. so perhaps best to leave that until UCM can just tell us without probing). After having spoken to Mark Brown at Plumber's, he does not expect UCM to handle HDA stuff in the near future, it will be something for the embedded world primarily and we will still have to rely on PA's mixer paths. So unfortunately, I wouldn't hope for UCM to be our great problem solver. 3) It'd be great if we could present something else than Microphone 1, Microphone 2 and so on when we have more than one mic input. Any idea of where this name actually comes from, and how we can make it better? I think ultimately from the table in ./modules/alsa/alsa-mixer.c There is a difference between internal and external microphones, so I guess making the distinction between front and rear and such like wouldn't hurt anyway... that said, WTF is the diffrence between a front and rear mic physically on a laptop? Do they *really* make laptops with two mics on them for this purpose? (from the names I'd have to expect a yes answer there, but seeing as my laptop has no built in mic, I'd say having two is just showing off :D)But more seriously, why are there front and rear mics? Is this forstereo recording? If so should these inputs be handled as a single, multichannel source rather than separate mono or stereo ones? I mean we don't expose
Re: [pulseaudio-discuss] [PATCH] alsa-sink: take base volume into account when applying hw volume
On 2010-12-01 11:31, Jyri Sarha wrote: Am currently working on a problem caused by safety-margin not taken into account when rewinding. When I get this fixed I'll add a fix for double use bug too. Hmm, for tsched or non-tsched? I think we merged a patch related to this from pl bossart a while ago. -- 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
[pulseaudio-discuss] Mic input volume controls
Hi folks, The way we control mic input is quite broken. I've tested here with both IDT codecs and Realtek codecs (the two most common HDA Codecs AFAIK) and as far as I see they're both broken in the same ways. Let's assume that we have an internal mic and an external mic jack, with autoswitching in the kernel. We have a Mic Boost affecting the external mic jack, a Front Mic Boost affecting internal mic, and a Capture control affecting both. Mic Boost and Front Mic Boost go from 0 to 60 dB in 20 dB steps, and Capture goes from 0 to 22.5 dB in 1.5 dB steps. 1) The first problem is PA is unable to combine both of them correctly: for the first 0 to 22.5 dB, PA moves the Capture control only. After that say at 25 dB, Mic Boost moves to +20 dB, keeping Capture at 22.5 dB, then using softvol to compensate, instead of lowering Capture. I've been suggested that changing the order of Mic Boost and Capture improves this situation, so we should probably do that. Any objections? 2) The harder problem is that PulseAudio does not know whether to control Mic Boost or Front Mic Boost, since it doesn't know what path is active at the moment. While we really need some kind of module, and appropriate kernel support, the question is what we do before that becomes sufficiently available. The next best solution, would probably be to have different profiles and manual autoswitching. While I yet have to look into the details, I guess we'll have to add different profiles for Mic, Front Mic, Rear Mic and so on, instead of having them in the same file as we have today. Any thoughts? 3) It'd be great if we could present something else than Microphone 1, Microphone 2 and so on when we have more than one mic input. Any idea of where this name actually comes from, and how we can make it better? Thanks/credits to Vitaliy Kulikov for helping with the analysis. -- 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
[pulseaudio-discuss] [PATCH] Add Rear Mic to alsa mixer paths.
This should be a patch without any controversy. Patch is against stable-queue. -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic From ff068f1dc07e086ba01b4a4db398d9d81f79f60b Mon Sep 17 00:00:00 2001 From: David Henningsson david.hennings...@canonical.com Date: Fri, 19 Nov 2010 10:41:46 +0100 Subject: [PATCH] Add Rear Mic to alsa mixer paths. Signed-off-by: David Henningsson david.hennings...@canonical.com --- .../alsa/mixer/paths/analog-input-mic.conf.common |9 + .../alsa/mixer/paths/analog-input.conf.common |4 2 files changed, 13 insertions(+), 0 deletions(-) diff --git a/src/modules/alsa/mixer/paths/analog-input-mic.conf.common b/src/modules/alsa/mixer/paths/analog-input-mic.conf.common index 4663305..9bddd48 100644 --- a/src/modules/alsa/mixer/paths/analog-input-mic.conf.common +++ b/src/modules/alsa/mixer/paths/analog-input-mic.conf.common @@ -62,6 +62,15 @@ name = input-boost-on [Option Front Mic Boost:off] name = input-boost-off +[Element Rear Mic Boost] +switch = select + +[Option Rear Mic Boost:on] +name = input-boost-on + +[Option Rear Mic Boost:off] +name = input-boost-off + [Element Int Mic Boost] switch = select diff --git a/src/modules/alsa/mixer/paths/analog-input.conf.common b/src/modules/alsa/mixer/paths/analog-input.conf.common index 6c5fae9..5e73ae6 100644 --- a/src/modules/alsa/mixer/paths/analog-input.conf.common +++ b/src/modules/alsa/mixer/paths/analog-input.conf.common @@ -90,6 +90,10 @@ priority = 19 name = input-microphone priority = 19 +[Option Input Source:Rear Mic] +name = input-microphone +priority = 19 + [Option Input Source:Line] name = input-linein priority = 18 -- 1.7.1 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] Man page clarifications
it is not strictly accurate to say the configuration file contains variable declarations; it contains variable assignments, not variable declarations; a configuration file (unless it is a script) normally cannot declare variables. ==man-pages naming consistency== The names of the man pages for /etc/pulse/* are default.pa, pulse-daemon.conf, and pulse-client.conf. Those names are a bit inconsistent. If the pulse prefix and .conf suffix are going to be used at all, they should be used consistently for all of them. Having said that, I'm not sure .conf is the best suffix. Anyway, the names need to make a clearer distinction between what are configuration scripts and what are configuration files. For example, per the paragraph above entitled man page for pulse-daemon.conf, default.pa should be renamed to something more specific like setup-script.cli for clarity. Also, referring to clients and servers is very widely understood; using clients and daemons is, well, a bit eccentric. There is potential to confuse users. Globally substituting server throughout the documentation would help improve consistency, e.g. man page pulse-daemon.conf - pulse-server.conf. ==grammar: when vs if== There are issues with grammar and logic in the first sentence of each of the man pages for default.pa, pulse-daemon.conf and pulse-client.conf. Paraphrasing it, it says, pulseaudio reads things from a file X and when that file does not exist from Y. The grammatical error is that when is being used as if it were a synonym for if, which it isn't. when is used for introducing time-dependent clauses in a sentence. if is used for introducing conditional clauses in a sentence. The second issue is a logical ambiguity. pulseaudio reads things from a file X and when that file does not exist from Y is logically ambiguous; it does not imply that pulseaudio does not read things from file X when both file X and file Y exist. so the user is left wondering what does happen in such a case. So, fixing the grammar, the ambiguity, and re-phrasing it less tersely: pulseaudio reads things from a file X. If file X exists, pulseaudio will not read anything from file Y. If and only if file X does not exist, pulseaudio reads things from file Y. Substitute X=~/.pulse/default.pa, Y=/etc/pulse/default.pa, things=configuration directives, and repeat with appropriate substitutions for each of the man pages. -- 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] [PATCH] volume: Fix incorrect usage of PA_VOLUME_IS_VALID
On 2010-10-19 15:43, pl bossart wrote: On Tue, Oct 19, 2010 at 3:56 AM, Colin Guthriegm...@colin.guthr.ie wrote: 'Twas brillig, and Arun Raghavan at 19/10/10 08:33 did gyre and gimble: The commit that introduced this macro was incorrect in some places. This patch fixes these. Thanks to Pierre-Louis Bossart for pointing this out. I thought I'd looked over all the cases where this was used to spot these as I was mindful that this could have been a problem easily introduced with this kind of change, but clearly I didn't do a good job. So much for that :s I've pushed this patch now as it's very obvious from looking at the changes that it's needed. Would be good if it did solve all of Pierre's issues too. This patch corrects the issue I reported. Thanks Arun. However I am now having problems with my multichannel files even when the same volume is applied for all tracks constant high frequency noise...more git bisect ahead of me... It would also be good to know is PULSE_NO_SIMD=1 affects the HF noise, and if switching to stable-queue affects the HF noise? -- 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] [PATCH 0/5] HW and SW volume syncronization in IO-thread
On 2010-10-13 18:40, o...@iki.fi wrote: From: Jyri Sarhajyri.sa...@nokia.com The first patch in the set gives sink implementor a possibility to synchronize HW and SW volume usage in IO-thread. The remaining patches implement the synchronization for the alsa-sink and add the necessary module parameters and defaults for them in daemon configuration. This code has been tested on Nokia's ARM based Meego platform, on i686 laptop and on amd64 desktop. Tanu Kaskinen has also reviewed the code. To check what this set of patches does, please try following: 1. play white noise in background on low volume: # pacat --fix-rate --volume=1 /dev/urandom 2. play a short transient stream with high volume while the noise plays in background: # dd if=/dev/zero count=200 | pacat --fix-rate --volume=65536 Without these patches on most hardware you hear an annoying snap either in the beginning or the end (sometimes both) of the transient stream.After applying the patch the snap should be gone or at least less audible. With a little fiddling of the parameters it should be possible to get rid of the snap on all hardware. The default parameters work well at least on my Lenovo T60 running Debian Squeeze and they should be good, maybe a bit conservative, for most HW out there. This patch is pretty much mandatory for proper usage of flat volume especially on less powerful HW. Thank you for your work! This is the main reason I've been advocating against enabling flat-volumes by default in Ubuntu, so I'm glad to see something that addresses the issue. The basic problem is that we can't have sample accurate volume changes, because no HW supports it. Right? So about the implementation - what you're saying is that it is better to have two guaranteed down-volume snaps rather than to risk an up-volume snap. That sounds reasonable, but are these down-volume transients hearable? Perhaps more hearable with playing a sine wave, rather than white noise? Anyway, I've been thinking of something like this but never looked more closely at implementing a solution, but I would probably have tried to do something like: start: 1) rewind 2) write stream with lower SW volume 3) wait until rewind margin has passed 4) raise HW volume end: 1) lower HW volume 2) rewind 3) write stream with higher SW volume ...rather than trying to add explicit delays just for the volume sync. Either that, or some kind of volume ramping. Just curious if you considered that solution as well? -- 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] [PATCH] SSE/MMX/ARM: Fix high frequency noise with unusual number of channels
We have got three confirmations that the patch is working in the bug below, so I believe it can be safely applied to both master and stable-queue. On 2010-10-08 19:00, David Henningsson wrote: I would kindly ask for comments for this patch before applying, just double-check that I thought the right way when fixing this one. BugLink: https://launchpad.net/bugs/445849 In the assembly optimized versions of SSE, a noise could occur when the number of channels were 3,5,6 or 7. For MMX and ARM, this could occur when the number of channels were 3. Signed-off-by: David Henningsson david.hennings...@canonical.com ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss -- 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] [PATCH] SSE/MMX/ARM: Fix high frequency noise with unusual number of channels
On 2010-10-13 09:53, Colin Guthrie wrote:
'Twas brillig, and David Henningsson at 13/10/10 07:27 did gyre and gimble:
We have got three confirmations that the patch is working in the bug
below, so I believe it can be safely applied to both master and
stable-queue.
Great!
Would you mind respinning the patch with a couple more inline comments?
I'm a little concerned about the lines such as channels = channels == 3
? 6 : PA_MAX()
It will be a bit disconcerting to read this in code without really
reading the relevant commit message, so I think a small hint towards why
this is done would be good here.
Thanks for reviewing the patch, I agree that a little clearer comment
wouldn't hurt, so here's a revised version.
--
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic
From 0bde1e26fd9b2b6c1cf3d914ad11347b0d852539 Mon Sep 17 00:00:00 2001
From: David Henningsson david.hennings...@canonical.com
Date: Fri, 8 Oct 2010 18:47:00 +0200
Subject: [PATCH] SSE/MMX/ARM: Fix high frequency noise with unusual number of channels
In the assembly optimized versions of SSE, a noise could occur when the
number of channels were 3,5,6 or 7. For MMX and ARM, this could occur
when the number of channels were 3.
Signed-off-by: David Henningsson david.hennings...@canonical.com
---
src/pulsecore/svolume_arm.c |5 -
src/pulsecore/svolume_mmx.c | 14 --
src/pulsecore/svolume_sse.c | 19 +--
3 files changed, 25 insertions(+), 13 deletions(-)
diff --git a/src/pulsecore/svolume_arm.c b/src/pulsecore/svolume_arm.c
index 5bd1448..fdd8f09 100644
--- a/src/pulsecore/svolume_arm.c
+++ b/src/pulsecore/svolume_arm.c
@@ -47,7 +47,10 @@ pa_volume_s16ne_arm (int16_t *samples, int32_t *volumes, unsigned channels, unsi
{
int32_t *ve;
-channels = PA_MAX (4U, channels);
+/* Channels must be at least 4, and always a multiple of the original number.
+ * This is also the max amount we overread the volume array, which should
+ * have enough padding. */
+channels = channels == 3 ? 6 : PA_MAX (4U, channels);
ve = volumes + channels;
__asm__ __volatile__ (
diff --git a/src/pulsecore/svolume_mmx.c b/src/pulsecore/svolume_mmx.c
index e50ebee..a71a39b 100644
--- a/src/pulsecore/svolume_mmx.c
+++ b/src/pulsecore/svolume_mmx.c
@@ -98,9 +98,10 @@ pa_volume_s16ne_mmx (int16_t *samples, int32_t *volumes, unsigned channels, unsi
{
pa_reg_x86 channel, temp;
-/* the max number of samples we process at a time, this is also the max amount
- * we overread the volume array, which should have enough padding. */
-channels = PA_MAX (4U, channels);
+/* Channels must be at least 4, and always a multiple of the original number.
+ * This is also the max amount we overread the volume array, which should
+ * have enough padding. */
+channels = channels == 3 ? 6 : PA_MAX (4U, channels);
__asm__ __volatile__ (
xor %3, %3\n\t
@@ -164,9 +165,10 @@ pa_volume_s16re_mmx (int16_t *samples, int32_t *volumes, unsigned channels, unsi
{
pa_reg_x86 channel, temp;
-/* the max number of samples we process at a time, this is also the max amount
- * we overread the volume array, which should have enough padding. */
-channels = PA_MAX (4U, channels);
+/* Channels must be at least 4, and always a multiple of the original number.
+ * This is also the max amount we overread the volume array, which should
+ * have enough padding. */
+channels = channels == 3 ? 6 : PA_MAX (4U, channels);
__asm__ __volatile__ (
xor %3, %3\n\t
diff --git a/src/pulsecore/svolume_sse.c b/src/pulsecore/svolume_sse.c
index 1cc4e0a..5983164 100644
--- a/src/pulsecore/svolume_sse.c
+++ b/src/pulsecore/svolume_sse.c
@@ -74,14 +74,19 @@
por %%xmm4, #s1\n\t /* .. | l h | */ \
por %%xmm5, #s2\n\t
+
+static int channel_overread_table[8] = {8,8,8,12,8,10,12,14};
+
static void
pa_volume_s16ne_sse2 (int16_t *samples, int32_t *volumes, unsigned channels, unsigned length)
{
pa_reg_x86 channel, temp;
-/* the max number of samples we process at a time, this is also the max amount
- * we overread the volume array, which should have enough padding. */
-channels = PA_MAX (8U, channels);
+/* Channels must be at least 8 and always a multiple of the original number.
+ * This is also the max amount we overread the volume array, which should
+ * have enough padding. */
+if (channels 8)
+channels = channel_overread_table[channels];
__asm__ __volatile__ (
xor %3, %3\n\t
@@ -159,9 +164,11 @@ pa_volume_s16re_sse2 (int16_t *samples, int32_t *volumes, unsigned channels, uns
{
pa_reg_x86 channel, temp;
-/* the max number of samples we process at a time, this is also the max amount
- * we overread the volume array, which should have enough padding. */
-channels
Re: [pulseaudio-discuss] [PATCH 0/5] volume: Decrease PA_VOLUME_MAX to be 2^31
On 2010-10-09 20:27, Arun Raghavan wrote: Hey folks, Here's a patchset to change PA_VOLUME_MAX to (2^31-1), which is about half its current value. This really should not impact anything significantly, since the maximum gain we can apply decreases from ~289 dB to ~271 dB. Why this change is good is that we can significantly simplify the software volume scaling arithmetic, since the volume can always be treated as a signed number. I am working on rewriting the volume scaling in Orc, Could you elaborate on this? Is Orc a programming language? Are you saying that native PulseAudio should only compile on compilers that have Orc support? and this would make that considerably simpler (and more fruitful, since we'd have to jump through hoops to deal with volumes= 2^31 while doing signed multiplication). If we choose to retain the old hand-optimised assembly, that should also benefit from this change. I'm not exactly sure where and for what PA_VOLUME_MAX is used, but does it correspond to 0 dB in any way? Thinking assembly, could it be that we have some e g fixed-point arithmetic that we must compensate? -- 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
[pulseaudio-discuss] [PATCH] SSE/MMX/ARM: Fix high frequency noise with unusual number of channels
I would kindly ask for comments for this patch before applying, just
double-check that I thought the right way when fixing this one.
BugLink: https://launchpad.net/bugs/445849
In the assembly optimized versions of SSE, a noise could occur when the
number of channels were 3,5,6 or 7. For MMX and ARM, this could occur
when the number of channels were 3.
Signed-off-by: David Henningsson david.hennings...@canonical.com
--
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic
From a7a099463370c1f49e470597fb7a70a6ac72d685 Mon Sep 17 00:00:00 2001
From: David Henningsson david.hennings...@canonical.com
Date: Fri, 8 Oct 2010 18:47:00 +0200
Subject: [PATCH] SSE/MMX/ARM: Fix high frequency noise with unusual number of channels
BugLink: https://launchpad.net/bugs/445849
In the assembly optimized versions of SSE, a noise could occur when the
number of channels were 3,5,6 or 7. For MMX and ARM, this could occur
when the number of channels were 3.
Signed-off-by: David Henningsson david.hennings...@canonical.com
---
src/pulsecore/svolume_arm.c |2 +-
src/pulsecore/svolume_mmx.c |4 ++--
src/pulsecore/svolume_sse.c |9 +++--
3 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/src/pulsecore/svolume_arm.c b/src/pulsecore/svolume_arm.c
index 5bd1448..ec9c08a 100644
--- a/src/pulsecore/svolume_arm.c
+++ b/src/pulsecore/svolume_arm.c
@@ -47,7 +47,7 @@ pa_volume_s16ne_arm (int16_t *samples, int32_t *volumes, unsigned channels, unsi
{
int32_t *ve;
-channels = PA_MAX (4U, channels);
+channels = channels == 3 ? 6 : PA_MAX (4U, channels);
ve = volumes + channels;
__asm__ __volatile__ (
diff --git a/src/pulsecore/svolume_mmx.c b/src/pulsecore/svolume_mmx.c
index e50ebee..5141d6c 100644
--- a/src/pulsecore/svolume_mmx.c
+++ b/src/pulsecore/svolume_mmx.c
@@ -100,7 +100,7 @@ pa_volume_s16ne_mmx (int16_t *samples, int32_t *volumes, unsigned channels, unsi
/* the max number of samples we process at a time, this is also the max amount
* we overread the volume array, which should have enough padding. */
-channels = PA_MAX (4U, channels);
+channels = channels == 3 ? 6 : PA_MAX (4U, channels);
__asm__ __volatile__ (
xor %3, %3\n\t
@@ -166,7 +166,7 @@ pa_volume_s16re_mmx (int16_t *samples, int32_t *volumes, unsigned channels, unsi
/* the max number of samples we process at a time, this is also the max amount
* we overread the volume array, which should have enough padding. */
-channels = PA_MAX (4U, channels);
+channels = channels == 3 ? 6 : PA_MAX (4U, channels);
__asm__ __volatile__ (
xor %3, %3\n\t
diff --git a/src/pulsecore/svolume_sse.c b/src/pulsecore/svolume_sse.c
index 1cc4e0a..afba877 100644
--- a/src/pulsecore/svolume_sse.c
+++ b/src/pulsecore/svolume_sse.c
@@ -74,6 +74,9 @@
por %%xmm4, #s1\n\t /* .. | l h | */ \
por %%xmm5, #s2\n\t
+
+static int channel_overread_table[8] = {8,8,8,12,8,10,12,14};
+
static void
pa_volume_s16ne_sse2 (int16_t *samples, int32_t *volumes, unsigned channels, unsigned length)
{
@@ -81,7 +84,8 @@ pa_volume_s16ne_sse2 (int16_t *samples, int32_t *volumes, unsigned channels, uns
/* the max number of samples we process at a time, this is also the max amount
* we overread the volume array, which should have enough padding. */
-channels = PA_MAX (8U, channels);
+if (channels 8)
+channels = channel_overread_table[channels];
__asm__ __volatile__ (
xor %3, %3\n\t
@@ -161,7 +165,8 @@ pa_volume_s16re_sse2 (int16_t *samples, int32_t *volumes, unsigned channels, uns
/* the max number of samples we process at a time, this is also the max amount
* we overread the volume array, which should have enough padding. */
-channels = PA_MAX (8U, channels);
+if (channels 8)
+channels = channel_overread_table[channels];
__asm__ __volatile__ (
xor %3, %3\n\t
--
1.7.1
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Alsamixertest
Hi Colin, for some reason your test of alsamixertest didn't reach me the normal path, so I'm pasting it in from the archives: Cool. Packaged up for Mandriva too now. Thanks :-) What license do you use. Couldn't seem to find any reference to it... It should be GPLv3, thanks for noticing. Ultimately the results seem to indicate that Master is OK, but out by a bit, Yeah, I have seen that on one of my test machines here as well, and I don't know if one should mark that as error, I probably shouldn't. I don't even know if that's a volume control or an ADC problem in that case. but PCM is all kinds of broken. PCM is indeed very broken. I've traced it down to alsactl as well, and if the decision was mine, I would remove it right away, but upstream wasn't convinced. :-( See the long thread starting at http://mailman.alsa-project.org/pipermail/alsa-devel/2010-August/031054.html FWIW, the testing for -18.0, expected -21.04 measure -20.03dB is all a little confusing. When testing for -18.0, why is 021.04 expected? Perhaps some more explanation would be nice as to why the expected values differ from the test value. So when it did the initial testing signal, it set everything to 0 dB and the input signal received was -3.04 dB. So when setting Master to -18 dB, it expects the input signal to be -18-3.04 = -21.04 dB. -- 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
[pulseaudio-discuss] Alsamixertest
So over the previous weeks I've been working on a small script which tests whether the ALSA mixer lives up to PA's expectations. If you are familiar with dbmeasure or dbverify by Lennart Poettering, this application's purpose is very similar, but this one is hopefully easier to set up, more user friendly, and also tests that the names of the volume controls are correct. My hope is that this will aid as a debugging tool for all these everything below 20% of my speaker is muted, and then 21% blows my speakers bugs. To use the tool, you'll need some kind of loopback. You can e g use a loopback cable and connect that between line in and line out, or test your laptop's internal speakers with your laptop's internal mic (just stop humming when you do so :-) ). Just set up the recording levels appropriately. Alsamixertest is available for Ubuntu Lucid and Ubuntu Maverick from these PPAs: Lucid: https://launchpad.net/~diwic/+archive/ppa Maverick: https://launchpad.net/~diwic/+archive/maverick For other distributions, download the tarball: https://launchpad.net/~diwic/+archive/ppa/+files/alsamixertest_47.14.tar.gz Unpack and read the readme file for compilation and install instructions. When it is installed, run alsamixertest -r for a small tutorial and alsamixertest -h for command line options help. Looking forward to your comments about this new little tool! I think it should be considered beta quality at this point. -- 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] [PATCH] Do not use tsched watermark if tsched is disabled
On 2010-09-13 13:03, Colin Guthrie wrote: 'Twas brillig, and David Henningsson at 13/09/10 11:14 did gyre and gimble: On 2010-09-04 14:10, Colin Guthrie wrote: 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? It is dash on Ubuntu systems. Perhaps just changing the first line to: #!/bin/bash would cause it to tidy things up properly? Yes, that worked, thanks. 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 problems, let's nail them down separately. OK, sounds reasonable. Do you think the patch I posted is OK with the 1330 time? I think it is good enough for now. If it turns out to be too little, we can adjust it later. I guess it's not super important as if it solves your original problem that kicked off this whole thread, then that's the main thing!! That PA can handle a stress test is important, but it's a different issue. -- 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] [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] [PATCH] Do not use tsched watermark if tsched is disabled
On 2010-09-08 02:52, pl bossart wrote: 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? Pierre, is it your understanding that it is when DMA transfer collides with cpu-RAM transfer that makes the DMA stream to become broken permanently? Or exactly what is it that makes it break? The low-latency setting has nothing to do with rewinds. Indirectly it is - if the rewind margin is greater than the actual latency there won't be any rewind. It's when you actually change the volume that you will rewind and remix with the new stream volume. You could set a super low latency and rewind exactly once when the stream starts. There are two issues with the rewind. One is a race condition between the DMA and the ring buffer update. If you rewind and update the ring buffer, the DMA may actually have already fetched older data. To fetch the old data is not a problem IMO, that gives us just a ms more of the old data and we might miss a ms of the new data. That's not optimal, but not a complete disaster either. What is the big problem here, is when we get a persistent crackling (even when everything has straightened out after the rewind!), and if I understand you correctly, that has something to do with the DMA controller...? Could you elaborate on what conditions it is that cause the persistent crackling? The second is that you could experience underflows if you don't do the update fast enough. By enabling logs you should be able to find out if there are real underflows. Exactly. -- 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] [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. I'm just guessing here, but I'm not sure you're experiencing the same problem then. It could be that you're having underruns from too high CPU usage instead, or something. And with tsched=0, we can't compensate by increasing the watermark. 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? Pierre, is it your understanding that it is when DMA transfer collides with cpu-RAM transfer that makes the DMA stream to become broken permanently? Or exactly what is it that makes it break? I'd be interested as to whether anyone else can repeat this experiment and get similar results. Unfortunately I haven't got around to test it yet :-( -- 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] [PATCH] Do not use tsched watermark if tsched is disabled
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. -- 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] [PATCH] Do not use tsched watermark if tsched is disabled
2010-09-01 20:06, pl bossart skrev:
Probably either one will work, but if we're about to release 0.9.22
(heard something from Lennart yet?), I suggest we go with my version for
0.9.22 as that one is the least invasive (only touches non-tsched
devices), and keep Pierre's version in master.
Sounds reasonable. Pierre, what's your take?
That would mean an additional post-release patch for tsched devices. I
am lazy and would prefer a one-stop fix. I don't care if this is
David's or mine, as long as the solution works for both cases.
The only real difference is the bytes/ms parameter. Although ms are
more intuitive, the bytes makes more sense from a hardware point of
view. If you pass a parameter in ms, there might be cases where the
actual number of bytes is lower than the DMA burst, it'll depend on
what frequency the sink operates at. There are some cases where
alsa-sink works at 8kHz (BT-SCO) or 48kHz (all other cases), a 6x
variability in the rewind behavior is difficult to handle.
Fair enough, how about the attached compromise (untested)? If you then
would like to turn the define of dma_rewind_margin_bytes into a
parameter, that should be fairly simple.
--
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic
From 5ae6c880e20adfa0f372f2caf293e70253651c5a Mon Sep 17 00:00:00 2001
From: David Henningsson david.hennings...@canonical.com
Date: Thu, 2 Sep 2010 08:22:36 +0200
Subject: [PATCH] ALSA: Fix calculation of rewind margins
For non-tsched devices, use 20 ms as a default rewind margin.
Also make sure that we have at least 256 bytes as rewind margin for
all devices, to avoid problems with DMA controllers.
Signed-off-by: David Henningsson david.hennings...@canonical.com
---
src/modules/alsa/alsa-sink.c | 13 -
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/src/modules/alsa/alsa-sink.c b/src/modules/alsa/alsa-sink.c
index a253cc5..097bb20 100644
--- a/src/modules/alsa/alsa-sink.c
+++ b/src/modules/alsa/alsa-sink.c
@@ -63,6 +63,9 @@
#define DEFAULT_DEVICE default
+#define NON_TSCHED_REWIND_MARGIN_USEC (20*PA_USEC_PER_MSEC)/* 20ms -- Default rewind margin for non-tsched devices */
+#define DMA_REWIND_MARGIN_BYTES (256) /* Make sure we're always have a rewind margin of at least 256 bytes - to avoid problems with some DMA controllers */
+
#define DEFAULT_TSCHED_BUFFER_USEC (2*PA_USEC_PER_SEC) /* 2s-- Overall buffer size */
#define DEFAULT_TSCHED_WATERMARK_USEC (20*PA_USEC_PER_MSEC)/* 20ms -- Fill up when only this much is left in the buffer */
@@ -1309,7 +1312,15 @@ static int process_rewind(struct userdata *u) {
return -1;
}
-unused_nbytes = u-tsched_watermark + (size_t) unused * u-frame_size;
+
+if (u-use_tsched)
+unused_nbytes = u-tsched_watermark;
+else
+unused_nbytes = pa_usec_to_bytes(NON_TSCHED_REWIND_MARGIN_USEC, u-sink-sample_spec);
+if (unused_nbytes DMA_REWIND_MARGIN_BYTES)
+unused_nbytes = DMA_REWIND_MARGIN_BYTES;
+
+unused_nbytes += (size_t) unused * u-frame_size;
if (u-hwbuf_size unused_nbytes)
limit_nbytes = u-hwbuf_size - unused_nbytes;
--
1.7.0.4
___
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
2010-09-02 10:41, Colin Guthrie skrev: 'Twas brillig, and David Henningsson at 02/09/10 07:29 did gyre and gimble: 2010-09-01 20:06, pl bossart skrev: Probably either one will work, but if we're about to release 0.9.22 (heard something from Lennart yet?), I suggest we go with my version for 0.9.22 as that one is the least invasive (only touches non-tsched devices), and keep Pierre's version in master. Sounds reasonable. Pierre, what's your take? That would mean an additional post-release patch for tsched devices. I am lazy and would prefer a one-stop fix. I don't care if this is David's or mine, as long as the solution works for both cases. The only real difference is the bytes/ms parameter. Although ms are more intuitive, the bytes makes more sense from a hardware point of view. If you pass a parameter in ms, there might be cases where the actual number of bytes is lower than the DMA burst, it'll depend on what frequency the sink operates at. There are some cases where alsa-sink works at 8kHz (BT-SCO) or 48kHz (all other cases), a 6x variability in the rewind behavior is difficult to handle. Fair enough, how about the attached compromise (untested)? If you then would like to turn the define of dma_rewind_margin_bytes into a parameter, that should be fairly simple. That patch works fine too with the chordtest test. In order to do more testing however, I also tried the following two cherry picks to stable-queue _instead_ of your patch: commit d11cd33e3aff14fdd66826b3252d90b1b0e38c48 Author: Lennart Poettering lenn...@poettering.net Date: Tue Feb 23 03:23:22 2010 +0100 alsa: don't make use of tsched related variables when tsched is disabled commit 4df443bbe682055a41e7c2248877dcc7682a69b8 Author: Pierre-Louis Bossart pierre-louis.boss...@intel.com Date: Thu Apr 29 10:48:11 2010 -0500 add rewind-safeguard parameter Rewinding the ring buffer completely causes audible issues with DMAs. Previous solution didn't work with tsched=0, and used tsched_watermark for guardband, which isn't linked to hardware and could become really high if underflows occurred. Added separate parameter that can be tuned to hardware limitations and size of DMA bursts. This approach also fixed the chordtest test case. Obviously to fix that test case, I'd rather cherry-pick those two patches than introduce a new patch only on stable-queue. David, as it's obvious that I'm not fully up-to-speed with how this alsa stuff works in any great depth, what do you think your patch adds on top of the above two? So my only worry, but I might be wrong, is that a fixed limit of 256 bytes in combination with high sample rates (think 8 channels, 192 kHz, 32 bit float, that will make 256 bytes 0,04 ms only), will not be enough. We'll rewind back and before we have time to fill it up again we will get an underrun (and possibly DMA failure?). So that's why I want to see a ms based margin as well as a byte-based one. For tsched devices, the watermark is a dynamic ms-based margin that seems to have been working well (AFAIK), but for non-tsched devices, we have had no margin at all, causing failure. As a summary, Pierre is afraid a ms-based one will rewind too far if the sample rate is low, and I'm afraid a byte-based one will rewind too far if the sample rate is high. My primary concern is that with the current git master version, the u-tsched_watermark is not used at all to calculate unused_nbytes, whereas in your patch it is (the usage of u-tsched_watermark was removed in git master in Pierre's patch above). Now I can see that the general aim in Peirre's change was to prevent rewinding too far, but with your patch it seems to stop it rewinding too little (have I interpreted this right?) and there is no upper limit on the amount rewound (in tsched mode with a massive watermark at least). Both patches aim not to rewind too far, if my one isn't, something is fundamentally wrong with my version. So is there still something missing in your patch? Can the rewind now be too much for the DMA controller (a problem alluded to in the comments in Pierre's fix). Right, I hope I've asked the right questions here. I'm aware that my not groking things fully isn't helping but I'm also keen to not cock things up :D In order to keep things sensible and prevent divergence, I think it's wise to cherry pick the above two patches to stable-queue and make any further change needed on top of that. This way the patch should apply to git master and stable-queue and I can prevent patch divergence and thus the strange reoccurances of problems post 0.9.22 when we ultimately release git master under whatever version it turns out to be. I think that makes sense. WDYT? 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
Re: [pulseaudio-discuss] [PATCH] Do not use tsched watermark if tsched is disabled
2010-08-19 07:32, Tanu Kaskinen skrev: On Wed, 2010-08-18 at 22:55 +0200, David Henningsson wrote: Yes the safeguard is needed in both cases, timer scheduling or good ol' audio interrupts. This comes from limitations of the snd_pcm_rewind() routine, you can rewind the appl_ptr all the way to the hardware pointer, but you may have DMA transfers in flight that cannot be rewound. For example HDaudio can fetch up to 128bytes, I added a default a safeguard of 256bytes to be super safe, but in theory this should be adjusted depending on how the DMA operates. Assuming your reasoning is correct (I'm not that deep into DMA yet), this should be fixed in the kernel - by not allowing rewinds further back than 128 (or 256) bytes ahead of actual position. You say HDA can transfer up to 128 bytes in advance, but what about all the other drivers? Could there be other drivers having a lot larger DMA fetches? What's the role of snd_pcm_rewindable()[1]? The documentation says Get safe count of frames which can be rewinded, which sounds to me like the function should always be called before snd_pcm_rewind(). Currently PA doesn't call _rewindable(). Good question. Looking at the code in alsa-lib, it seems like both snd_pcm_avail and snd_pcm_rewindable call snd_pcm_mmap_hw_avail, so in practice it probably doesn't matter, at least not for the common cases. That said, it would likely be a good thing to change it anyway, since the alsa-lib implementation might change. The DMA knows nothing about milliseconds, it behaves the same way no matter the sampling rate it, which is the reason why bytes make more sense, it's easier to correlate with the way the hardware works. So your idea is to prevent DMA transfers being modified, but I'm thinking of the maximum duration between the rewind and the point it gets filled up again by PA - all of that time we risc getting an XRUN because there is nothing in the buffer. And so I assume that the duration is never longer than 20 ms. I don't think it is much of a deal though. Rewind is not something used every second or so (or at least, shouldn't be). A comment on the last statement: I don't think the average frequency of rewinds is important, because there are cases where multiple rewinds do happen really quickly - for example when dragging a volume slider (IIRC pavucontrol ratelimits the volume change events to minimum of 100ms between each event sent to the daemon - that's still ten times a second). I don't remember hearing complaints about that the volume is crackling when changing volumes, but at least in theory this seems like a possible problem with the current implementation. Ah, are you saying we might have fixed that crackling as well? That would be even better :-) For volume slider changes I don't think there is a problem with waiting 20 ms before the volume change takes effect. -- 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] Version numbers rollup releases
2010-08-18 18:01, Colin Guthrie skrev: Now on to the next point: More frequent releases. I know that Lennart doesn't like doing releases, but I think I speak for everyone of us triaging bugs and working on patches for the stable-queue branch would prefer to have more interim releases (especially in the current case where 0.9.22 has been so long in the kitchen due to systemd distractions!). At least you speak for me :-) Thanks for bringing it up, I totally agree. So, in short, I'd like to take the following actions: 1. Rename the milestone 0.9.22 to 0.10.0. The current git master should ultimately become 0.10.0 (with all it's DBUS funkiness). 2. Tag stable-queue as 0.9.22 and release a tarball[1] Lennart: As always you are in charge, but keeping a track on things is so much easier if I don't have to explain the fact that there are 170+ patches to apply on top of the last stable release. If you are happy to adopt this numbering approach, I'll take the extra load that results from doing more interim releases. I know that distro policy means that version bumps in packages for stable distros are generally frowned upon by distro release managers, but I get the feeling that this is slightly more relaxed these days (I know it is in Mandriva) if the upstream project is quite clear about their recommendations and their versioning scheme. I mean if 0.10.x is basically the official, upstream recommended version of the 0.10 series then distros can rest easy in updating 0.10.0 to 0.10.1 in a stable distro. This wont always work if the distro is too strict but it's still a generally sensible approach to versioning. So, what do you think? Agreed. If master was stabilized and had a new release once a few months or so, things would be different, bug given current state of master and stable-queue it makes sense to let them have separate number series. 1. Only after the either David's or Pierre's patch for fixing tsched=0 mode is merged into s-q tho' :D Yes please :-) Hope we don't get stuck in never-ending discussions on that one. -- 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] [PATCH] Do not use tsched watermark if tsched is disabled
2010-08-17 21:10, Colin Guthrie skrev: 'Twas brillig, and David Henningsson at 17/08/10 19:20 did gyre and gimble: According to what you say in that bug, you could reproduce it yourself by setting tsched=0, so I'm eager to hear if this fix fixes your issue as well. Yeah I was able to reproduce it pretty easily with the chordtest.sh script attached to the bug. After the third tone, it started to sound terribly distored. After applying your patch, I tried several times and got a perfect run each time :) \o/ The patch is against stable-queue, and Raymond commented that git master has a slightly different way of solving the problem. To compare them: * Pierre-Louis Bossart's version in git master sets a fixed margin of 256 bytes, (configurable if you load the sink manually, i e not through module-udev-detect). * My version sets a fixed margin of 20 ms. * My version only changes non-tsched devices and keeps tsched having a margin of the current watermark, whereas Bossart's version changes both. I think a margin should be based on milliseconds rather than bytes (the amount of bytes varies with amount of channels, which means that we might get problems when people switch to surround output). I don't have an opinion on whether a fixed margin or watermark-based margin is better for tsched sinks. -- 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] [PATCH] Do not use tsched watermark if tsched is disabled
2010-08-18 19:19, pl bossart skrev: * Pierre-Louis Bossart's version in git master sets a fixed margin of 256 bytes, (configurable if you load the sink manually, i e not through module-udev-detect). * My version sets a fixed margin of 20 ms. * My version only changes non-tsched devices and keeps tsched having a margin of the current watermark, whereas Bossart's version changes both. I think a margin should be based on milliseconds rather than bytes (the amount of bytes varies with amount of channels, which means that we might get problems when people switch to surround output). I don't have an opinion on whether a fixed margin or watermark-based margin is better for tsched sinks. I presume Pierre-Louis will comment in due course. I'm sure he'll see this message. I'm annoyed I didn't appreciate that his fix would likely address the issue too when it was pushed, but such is life :D Well I didn't see the link between my patch (from April) and the problem David tried to fix either. Thanks Raymond for finding this out. Before making any conclusions, would the problem be solved with David's patch using the equivalent of 256 bytes, that is 1.45ms instead of 20ms? just want to make sure this is the same bug. Haven't tested, but I feel quite certain that it's the same one. Yes the safeguard is needed in both cases, timer scheduling or good ol' audio interrupts. This comes from limitations of the snd_pcm_rewind() routine, you can rewind the appl_ptr all the way to the hardware pointer, but you may have DMA transfers in flight that cannot be rewound. For example HDaudio can fetch up to 128bytes, I added a default a safeguard of 256bytes to be super safe, but in theory this should be adjusted depending on how the DMA operates. Assuming your reasoning is correct (I'm not that deep into DMA yet), this should be fixed in the kernel - by not allowing rewinds further back than 128 (or 256) bytes ahead of actual position. You say HDA can transfer up to 128 bytes in advance, but what about all the other drivers? Could there be other drivers having a lot larger DMA fetches? The DMA knows nothing about milliseconds, it behaves the same way no matter the sampling rate it, which is the reason why bytes make more sense, it's easier to correlate with the way the hardware works. So your idea is to prevent DMA transfers being modified, but I'm thinking of the maximum duration between the rewind and the point it gets filled up again by PA - all of that time we risc getting an XRUN because there is nothing in the buffer. And so I assume that the duration is never longer than 20 ms. I don't think it is much of a deal though. Rewind is not something used every second or so (or at least, shouldn't be). -- 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
[pulseaudio-discuss] [PATCH] Do not use tsched watermark if tsched is disabled
The tsched watermark variable was incorrectly used even for sinks
with timer scheduling disabled, causing XRUNs on every rewind. This
patch sets a fixed margin of 20 msec for such rewinds, thus avoiding
the underrun.
One could argue that the margin should be adjustable somehow (or based
on fragment-size, or something else), but this patch at least fixes the
immediate problem, causing crackling output on (at least) one machine.
--
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic
From 87e8a04f029c18cdb5abebb4f3f3c2100d42107a Mon Sep 17 00:00:00 2001
From: David Henningsson david.hennings...@canonical.com
Date: Tue, 17 Aug 2010 19:37:51 +0200
Subject: [PATCH] Do not use tsched watermark if tsched is disabled
The tsched watermark variable was incorrectly used even for sinks
with timer scheduling disabled, causing XRUNs on every rewind. This
patch sets a fixed margin of 20 msec for such rewinds, thus avoiding
the underrun.
Signed-off-by: David Henningsson david.hennings...@canonical.com
---
src/modules/alsa/alsa-sink.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/src/modules/alsa/alsa-sink.c b/src/modules/alsa/alsa-sink.c
index a253cc5..9202883 100644
--- a/src/modules/alsa/alsa-sink.c
+++ b/src/modules/alsa/alsa-sink.c
@@ -63,6 +63,8 @@
#define DEFAULT_DEVICE default
+#define NON_TSCHED_REWIND_MARGIN_USEC (20*PA_USEC_PER_MSEC)/* 20ms -- Rewind margin for non-tsched devices */
+
#define DEFAULT_TSCHED_BUFFER_USEC (2*PA_USEC_PER_SEC) /* 2s-- Overall buffer size */
#define DEFAULT_TSCHED_WATERMARK_USEC (20*PA_USEC_PER_MSEC)/* 20ms -- Fill up when only this much is left in the buffer */
@@ -1309,7 +1311,11 @@ static int process_rewind(struct userdata *u) {
return -1;
}
-unused_nbytes = u-tsched_watermark + (size_t) unused * u-frame_size;
+unused_nbytes = (size_t) unused * u-frame_size;
+if (u-use_tsched)
+unused_nbytes += u-tsched_watermark;
+else
+unused_nbytes += pa_usec_to_bytes(NON_TSCHED_REWIND_MARGIN_USEC, u-sink-sample_spec);
if (u-hwbuf_size unused_nbytes)
limit_nbytes = u-hwbuf_size - unused_nbytes;
--
1.7.0.4
___
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
2010-08-17 20:03, Colin Guthrie skrev: 'Twas brillig, and David Henningsson at 17/08/10 19:00 did gyre and gimble: The tsched watermark variable was incorrectly used even for sinks with timer scheduling disabled, causing XRUNs on every rewind. This patch sets a fixed margin of 20 msec for such rewinds, thus avoiding the underrun. One could argue that the margin should be adjustable somehow (or based on fragment-size, or something else), but this patch at least fixes the immediate problem, causing crackling output on (at least) one machine. /me wonders if this fixes https://bugzilla.redhat.com/show_bug.cgi?id=537378 It seems likely to me. I got a feeling that it isn't the whole story though, that there could be some additional bug in ALSA causing sound to remain distorted, if the XRUN is merely touched and afterwards immediately resolved by writing more data. So it could have been a combination of these two bugs causing the crackling sound, and by resolving the PA bug the problem does not appear anymore. According to what you say in that bug, you could reproduce it yourself by setting tsched=0, so I'm eager to hear if this fix fixes your issue as well. -- 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
[pulseaudio-discuss] Wait on sound cards before starting PA, and stream routing
We had a problem with PA a few days ago which I analyzed as the following: PA started up for the first time, i e without a .pulse directory. Due to racy startup conditions (we're all trying to boot up as quick as possible nowadays), sometimes the start order was as follows: 1) Sound card #2 was probed and announced from the kernel 2) PA was started up and found sound card #2 3) Some client or module asked for the fallback/default device 4) Since there was no current default device, it was auto-set to sound card #2 5) Sound card #1 was probed and announced from the kernel, but was not selected as default - even if the priority was higher, since the default had already been set. My workaround was to write a simple wait-on-file-access module that waited for /dev/snd/controlC0 and /dev/snd/controlC1 before continuing, and then I placed that one on the top of /etc/pulse/default.pa for this particular hardware. I found it the least ugly workaround at the time, and should upstream be interested in merging this module, I'd be happy to prepare a git patch for either master or stable-queue as you see fit. The long-term solution - and this is more my own thoughts than an official standpoint from Canonical - probably would include writing something that takes on the entire problem of deciding stream routing, because now we have many modules which all try to solve their piece of the puzzle, but instead end up shooting each other's feet. I know Colin have done a lot of work in this area already (thank you Colin!), and so Colin, it would be nice to have a little status update: - Did the implementation turn out the same way you described in your February blog post? - Is this ready for testing in pulseaudio git master? - What remains until this is ready for everyday usage? -- 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] Auto switching outputs
2010-08-05 05:00, Erik de Castro Lopo skrev: Hi all, I've acquired a pair of wireless headphones; the type that has a USB dongle that plugs into my machine and uses analog FM to communicate with the headphones. These JustWorked(tm) under linux, but now I'd like to have audio (either PulseAudio or ALSA) auto switch to the headphones whenever they are plugged in. Is this doable? Any hints? Cheers, Erik There is also module-switch-on-connect (see ticket http://pulseaudio.org/ticket/706 ). I'm a little hesitant to whether it actually does the right thing in all cases though, and Colin's work in progress is probably a more complete solution, once it is easily accessible, but I think it does what you want for now. Michael, will you update the ticket with the changes you did yesterday? -- 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 debug mode
On 2010-07-23 03:04, Chris wrote: What is the best way to start PA for debugging and still have all the usual clients running? pacmd set-log-level 4 ...if your log target is set to syslog, just watch it grow :-) -- 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] Weird data flow (not waveform)
On 2010-06-15 20:49, José Tomás Tocino García wrote: I think that's not the problem, because Gnuplot does not expect a exact format, it renders whatever it gets. The thing is, a usual waveform gets positive and negative values all the time. Sometimes that's what some DSP algorithms use to measure frequency, but given the stream has this weird representation, they do not work. That's what bugged me in first place, so I used gnuplot to visually check the waveform. Isn't is supposed to be a PCM waveform? Yes it is. If your mic has a DC offset you might get only negative or only positive levels though. What sample spec are you using in your call to pa_simple_new? Perhaps you have to specify the exact format for gnuplot, if it guesses wrong. By the way, there are plenty of programs that do simple recording - arecord, parecord, audacity etc should be able to do that as well. // David ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] M-audio fasttrack pro: fix input device string
On 2010-05-25 01:26, Lennart Poettering wrote: On Wed, 19.05.10 01:00, David Henningsson (launchpad@epost.diwic.se) wrote: Heya, Sometimes the input device shows up at device ID 0, and sometimes device ID 1, so try both. Humpf. Why is that so? The driver authors presumably have a reason for this assignment, and before we merge something like this we should figure out what's going on and how we should label this. We currently label that mapping Analog Streo Channel A. It appears to me that that mapping label might not be accurate anymore after such a change. AFAIK this sound card is just using the standard USB Audio drivers. I don't have access to this particular hardware either, so I'm not in a position to debug the drivers ATM. So I can't answer your question and my guess is that it varies between hardware revisions. Perhaps David Kågedal, who wrote the initial profile, knows more about this? // David ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Help with Udev Please
I just upgraded from fc11 to fc12. With fc12 comes PA 0.9.21.
Pulseaudio fails to detect any of my audio cards, I have two cards.
I'm positive the problem is with UDEV. When I boot the system,
I'm getting a cryptic message from udev about some {ATTR ... uvent}
file not found. I'm having trouble getting the error message to
report, it flies off the screen before I can record it.
Looks like a syntax error in one of the udev rules.
Perhaps you can see if the message shows up in /var/log/syslog and then
grep for that string in the udev rules directory?
// David
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Problems with mplayer in Ubuntu 10.04
On 2010-05-09 13:06, Mihai Sucan wrote: The problem is with mplayer. I cannot play *any* sound with it, and worse, it causes PulseAudio to go bonkers. Once I start mplayer, I cannot hear any sound, from any application. I tested mplayer from the default Ubuntu repositories [1] and a much newer build from the RVM Ubuntu PPA repository [2] (the author of SMPlayer, if I am not mistaken). Both behave quite much the same. I'm not sure, but this could be worth a look: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=580113 ...to see if that is what you have encountered as well, or if it is related. // David ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] rtkit: add pid as argument
On 2010-04-25 22:11, Lennart Poettering wrote: On Sun, 25.04.10 21:41, David Henningsson (launchpad@epost.diwic.se) wrote: which handle corresponds to the thread, or even if that handle is local or not. Wineserver controls this information so all requests that involve handles involve a wineserver call, in general. So racing cannot happen, because wineserver is the only one making the requests. Just a question, what about RLIMIT_RTTIME, which rtkit requires to be set for enabling rt? AFAIK there is no equivalent in Windows. Well, we enforce RLIMIT_RTTIME mostly because we can, not because it would really inhibit all kind of RT-related misbehaviour of the clients. Or in other words: RLIMIT_RTTIME is quite useful as a protection against programming errors somewhre, however it is still easily circumventable by people who really try to do evil things, unless combined with other tricks, such as SCHED_RESET_ON_FORK. So let my rephrase my question to Maarten: Since there is no equivalent to RLIMIT_RTTIME in Windows, applications might assume they can run in RT for extended periods of time. This might be considered bad application behavior in any operating system, but nonetheless - do we risc regressions when these applications are being killed, instead of the previous behavior which just let them run in non-RT? // David ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] rtkit: add pid as argument
Maarten Lankhorst wrote: Well, the use case would be wine's wineserver. On windows programs usually set audio threads to THREAD_PRIORITY_TIME_CRITICAL to indicate that they have to have a certain priority. But in windows thread handles are global, so doing it inside wine's 'ntdll' library wouldn't make much sense, since the request to set the priority would go to wineserver first, since there's no way to tell from inside a wine program to tell which handle corresponds to the thread, or even if that handle is local or not. Wineserver controls this information so all requests that involve handles involve a wineserver call, in general. So racing cannot happen, because wineserver is the only one making the requests. Just a question, what about RLIMIT_RTTIME, which rtkit requires to be set for enabling rt? AFAIK there is no equivalent in Windows. // David ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] pulse: Fix invalid buffer pointer return value
Nix wrote: On 18 Apr 2010, David Henningsson spake thusly: Both of them were tested by Daniel, and AFAIK neither have been applied upstream. These are both alsa-plugin things, right? Yes. In that case, they can't fix the hangs I reported back in February, since these are hangs experienced even --- especially --- with native PA applications such as mpd, when seeking. Correct, since alsa-plugins is not in the audio stack in that case. // David ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] pulse: Fix invalid buffer pointer return value
Colin Guthrie wrote: 'Twas brillig, and David Henningsson at 16/01/10 07:07 did gyre and gimble: David Henningsson wrote: Lennart Poettering wrote: On Sat, 09.01.10 10:00, David Henningsson (launchpad@epost.diwic.se) wrote: The pulse ALSA plugin has been known, for a while, to not work properly, causing underruns, hangs etc. I sat down yesterday trying to figure it out, and I'm pretty certain this patch improves the situation, but I don't mind getting some help testing it before it is committed upstream. I am kinda convinced that the actual fix for this issue is this patch. Could you check that? http://git.0pointer.de/?p=pulseaudio.git;a=patch;h=8d356659e69556fa25d0579a66084f820683e2b8 I have now checked it with the latest version of pulseaudio and without my patch posted earlier, I still experience hangs. That and positive feedback given from https://bugs.launchpad.net/bugs/485488 makes me believe that the patch is ready for inclusion upstream (it is already in Ubuntu, thanks Dan). Now onto the next problem. If an underrun occurs in the pulseaudio front-end, it is delivered asynchonously to an underrun callback. This sometimes happens after more buffers are sent (through pa_stream_write()). So these new buffers will end the underrun in parallell with the processing of the underrun in the client, making the underrun obsolete. After all, seen from the client program's perspective, if I write a buffer and it returns underrun (-EPIPE), I assume that all other buffers I've written, which returned successfully, have already been played back. The best action in this case should be to ignore the underrun, if I can determine that the above case is true. Now, how do I do that? I have tried to look at pa_stream_get_timing_info() [1], but I can't find a reliable way to distinguish valid underruns from obsolete ones. // David [1] which needs to be updated, and I can't use pa_wait_operation from the callback so I'll have to use a second callback for the timing info... Just pinging this one up. I forgot I'd applied this to my own personal alsa-plugins build and only noticed it when I updated to 1.0.23 upstream version. I've not seen any specific problems with this but also not sure what it fixes. It fixes (at least) the mpg123 startup race (which lead to dropped buffers on an underrun). Is this still applied in Ubuntu Daniel Chen volunteered to do some testing and he found no regressions, so he applied my remove underrun handling patch, and AFAIK it is still applied. I haven't heard of any regressions so far, so I believe it should be pretty safe to upstream. and should we get further review from Lennart when he's got a mo (which is sadly not often in recent months) about the issue with a view to getting it upstreamed? Lennart's, anyone else's opinion, and upstreaming, is very welcome. If you feel I should do something to help this happen, go ahead and tell me. :-) // David ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Sources only working when pavucontrol is running
Brendon Costa wrote: Hi again, Thanks for the info on the default devices. I have it working fine now. However I have run into another problem. When I run my application, the sinks are working fine and audio sounds good. However the sources are not working correctly. If i run my app, i get occasional bursts of sound from whatever source I am using instead of a continuous stream of audio. If while my app is running i then start the pavucontrol application, everything seems to magically start working perfectly. Somehow starting the pavucontrol application fixes whatever problem my application is experiencing. Does anyone know what the pavucontrol application does that might be affect my application? Pavucontrol opens all sources and sinks to provide peak meters. Does anyone know if it changes the priority of the server or change buffer sizes etc? Any suggestions on what i can do to track this problem down? Perhaps you could try making a log for both scenarios and compare them, and see if there is anything unusual? Here's how to do it on Ubuntu, I assume it's very similar on most other modern distros: https://wiki.ubuntu.com/PulseAudio/Log // David ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] Fix crash on jack server shutdown
Lennart Poettering wrote: On Tue, 23.03.10 00:36, David Henningsson (launchpad@epost.diwic.se) wrote: What is missing is that the jack loop does not depend on the PA sink to be around resp. the PA IO loop doesn't call into jack when it is dead. If either of that is implemented (and then destruction order matches this) the problem is fixed. Also, what applies to m-jack-sink needs fixing in m-jack-source, too. Good points. I admit to not having checked properly whether pa_sink_unlink and pa_sink_render_full can be called in parallell, I see now that they shouldn't. Calling _unlink() and _render_full() at the same time is actually fine. _unlink() will send a msg to the IO thread to shut down the sink and will synchronously wait for it. _render_full() is called from the IO thread. Since the msg dispatching and the _render_full() are run from the same thread and hence are serialized there is no problem here. Oh, so pa_sink_unlink does synchronize with the IO thread. But then I don't see the new race? What call into pa would be a problem after the sink has been unlinked? It can't be sink rendering, as u-sink-thread_info.state != PA_SINK_RUNNING at that point, so the module will just write silence (and not call into pa). // David ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] Fix crash on jack server shutdown
Lennart Poettering wrote: On Sun, 14.03.10 20:50, David Henningsson (launchpad@epost.diwic.se) wrote: On sink unlinking, existing sink inputs are moved, which in turn calls a get latency callback, which references the jack client. Therefore, make sure the sink is unlinked before the client is closed. Failure to do so might lead to SIGSEGV. This patch simply moves the call to pa_sink_unlink above jack_client_close, which fixes the problem. Uh. I don't think this really fixes the problem. This just moves things around and replaces one race by another. The old race: the PA IO loop might end up calling into libjack with an invalid jack client context after the context got destructed but the PA sink didn't get shutdown yet. The new race: the jack IO loop might end up calling (and blocking) into PA code when the PA sink is unlinked (though not yet destructed) but the jack code is not yet. What is missing is that the jack loop does not depend on the PA sink to be around resp. the PA IO loop doesn't call into jack when it is dead. If either of that is implemented (and then destruction order matches this) the problem is fixed. Also, what applies to m-jack-sink needs fixing in m-jack-source, too. Good points. I admit to not having checked properly whether pa_sink_unlink and pa_sink_render_full can be called in parallell, I see now that they shouldn't. Since appropriate stream moving is good, and stream moving (apparently) needs to do a get-latency call to do its job properly, I would say that this was a step in the right direction. So, let us also send a message to the thread to stop rendering (i e stop calling pa_sink_xxx), before the pa_sink_unlink call? If this sounds like a good idea to you, I'll prepare a git patch. // David ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH] Fix crash on jack server shutdown
On sink unlinking, existing sink inputs are moved, which in turn calls
a get latency callback, which references the jack client. Therefore,
make sure the sink is unlinked before the client is closed. Failure to
do so might lead to SIGSEGV.
This patch simply moves the call to pa_sink_unlink above
jack_client_close, which fixes the problem.
Steps to reproduce:
1. Disable autospawn and kill PA
2. Start jack server
3. Start PA
4. Load module module-jack-sink
5. Start a stream (e g Rythmbox) and run it through the jack sink.
6. Shutdown the jack server. Now PA crashes with SIGSEGV.
@Daniel T Chen: let me know if you want this patch as a merge proposal as
well. There is no bug in Launchpad AFAIK.
From fa2dcce3201753bff94adba99b6bc36a7eaf57f9 Mon Sep 17 00:00:00 2001
From: David Henningsson di...@ubuntu.com
Date: Sun, 14 Mar 2010 20:20:12 +0100
Subject: [PATCH] Fix crash on jack server shutdown
On sink unlinking, existing sink inputs are moved, which in turn calls
a get latency callback, which references the jack client. Therefore,
make sure the sink is unlinked before the client is closed. Failure to
do so might lead to SIGSEGV.
---
src/modules/jack/module-jack-sink.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/modules/jack/module-jack-sink.c b/src/modules/jack/module-jack-sink.c
index 9f3e071..e4467d3 100644
--- a/src/modules/jack/module-jack-sink.c
+++ b/src/modules/jack/module-jack-sink.c
@@ -475,12 +475,12 @@ void pa__done(pa_module*m) {
if (!(u = m-userdata))
return;
-if (u-client)
-jack_client_close(u-client);
-
if (u-sink)
pa_sink_unlink(u-sink);
+if (u-client)
+jack_client_close(u-client);
+
if (u-thread) {
pa_asyncmsgq_send(u-thread_mq.inq, NULL, PA_MESSAGE_SHUTDOWN, NULL, 0, NULL);
pa_thread_free(u-thread);
--
1.7.0
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Frequent trivially-reproducible client hangs with stable-queue PA
well. (I'd use the ALSA-PA plugin, but as reported earlier, this doesn't work either, stuttering like crazy and frequently locking up. Even with this patch? http://launchpadlibrarian.net/37640450/0001-pulse-Fix-buffer-pointer-issues-improves-recovering-.patch // David ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Invalid dB data from drivers
Heya, just wanted to point everybody to this new canned response type note I just added to the wiki: http://pulseaudio.org/wiki/BadDecibel I wrote a little tool that can be used to track invalid dB data exposed by ALSA drivers. Incorrect dB data usually means that playing a stream in PA while another one is already playing might result in a volume change of the first one, that should not happen. As it appears a lot of USB hw has issues with the dB information. Anyway, I though you might find that page and the tool useful, especially if you maintain PA in other distributions and want to know what to do with bug reports about issues like the one I pointed out above. Did this tool go almost unnoticed, at least on this list? Thanks! I'm sure it'll come in handy when we triage some of the bugs in Ubuntu. Perhaps it could be something for the hardware testing suite, both in Ubuntu (i e checkbox), and its counterparts in other distributions? Now if only I could get some spare time, so I could play with it and package it...and optimally, I also need to get a soundcard with bad dB information from somewhere... Have fun, I've always enjoyed sine waves. ;-) // David ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] What is latency? And other related questions
Tristin Celestin wrote: Is there a downside to making a version of pa_stream_writable_size available in the simple API? Good question. In your use case, can see the use for a function returning how many bytes that can be written to pa_simple_write without pa_simple_write blocking. Why would I want to specify the buffer attributes in the simple API with a buffer_attr, but not be able to query the state of the buffer while writing to it? If there is no free space in the buffer, the simple API blocks until all data you send to it has been written to the buffer. This is a good approach for some applications, although your app doesn't seem to be one of them. Perhaps it is a PA design decision that apps that don't want pa_simple_write to block, shouldn't use the simple API, I don't know. The tlength still controls the latency, and so it is still useful. E g, I've been reviewing the PA output module for FluidSynth and there both the simple API and setting tlength make sense. // David ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
Lennart Poettering wrote: On Tue, 09.02.10 22:52, David Henningsson (launchpad@epost.diwic.se) wrote: There are just too many people for where the ordinary PA setup (all soundcards are of exclusive use to the person logged into the current X session) is not acceptable, and worse, it isn't easy for them to either reconfigure PA, or replace PA, with something that suits their needs. I doubt the too many. Let's conclude that our milages vary, then. The handful of people coming up with this from time to time is fairly minimal, I you allow me to say so. Oh. Most of the people don't complain here. They go googling and find solutions such as stacking PA on top of dmix, using alsa-plughw directly from an application, remove all traces of PA from the system, etc etc, with various degree of success. Sometimes the information is meant for another distro or version, and they end up messing up more than they fix. Anyway, reading this thread has been helpful and I got a few pointers. I'll see if I can sum it up in one page to make the information more accessible. // David ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
Lennart Poettering wrote: On Wed, 10.02.10 07:14, David Henningsson (launchpad@epost.diwic.se) wrote: But printers are more of a system-wide resource, and for some use cases, so is the soundcard. This is nonsense. I am not sure how your ears are constructed, but on a multiseat system if you want to share a soundcard between two seats, where would you put the speakers so that the two users have the same distance from L and R and they are on the left and the right side? I mean, those users would have to sit on top of each other or detachable ears or something. Detachable ears seems cool, although I'd prefer headphones. Anyway, multiseat wasn't the use case I was talking about here, I was more thinking of the use computer as combined desktop workstation and independent media player for the kitchen use case. We discussed this with a couple of folks long time ago, and decided that some reasources are per-seat resources, and should be configured like that. Those devices are keyboards, mice, screens, sound cards, webcams and a couple of others. the UDEV_ACL=1 property in the udev tree marks most of them. This discussion was mostly done on the udev level btw, it is only indirectly related to PA. Now, in some non-standard cases it might make sense to have the access rules deviate from this default, but those are the exceptions, not the common cases. And that means that you configure it that way, but the default will be the safe, common case, not the dangerous uncommon case. Exactly. BTW, I really do not know why I am even responding, Neither do I. If I knew what makes you respond to some posts and leave others behind, I would have used that knowledge to make you respond to the alsa-plugins patch I suggested earlier [1]. Do you know this Google thing? It's kinda cool, you should try it. Never heard of it. I'll go search for it and see if I find something. And then, sharing makes sense. If another user is allowed to print a document while I'm logged in, why shouldn't he be able to play a sound? So would then the solution be to run PA as a system-wide daemon, and possibly assign soundcards to it via udev? Right, allow every user to listen into all voip calls, You're mixing the use cases up. The soundcards you use to make voip calls, are not necessarily the ones you want to share with other users. Lemme guess, you disable access control to your X11 screen too? There are use cases for that as well, but we can leave them out for now. // David [1] https://tango.0pointer.de/pipermail/pulseaudio-discuss/2010-February/006471.html ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
Colin Guthrie wrote: 'Twas brillig, and Jeremy Nickurak at 09/02/10 19:24 did gyre and gimble: This whole thing has been discussed to death, and I really don't feel like being drawn into the whole thing again. From what I've read here, I'm afraid it's going to keep coming up until we solve it somehow. There are just too many people for where the ordinary PA setup (all soundcards are of exclusive use to the person logged into the current X session) is not acceptable, and worse, it isn't easy for them to either reconfigure PA, or replace PA, with something that suits their needs. I wrote down a few use cases here, I'm sure there are more: https://wiki.ubuntu.com/BluePrints/multiuser-soundcards-pulseaudio Let's hope we can get something constructive out of this, and I'm hopeful we can solve those people's problems, without sacrificing latency, power usage or security. // David ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
Colin Guthrie wrote: 'Twas brillig, and David Henningsson at 09/02/10 21:52 did gyre and gimble: I wrote down a few use cases here, I'm sure there are more: https://wiki.ubuntu.com/BluePrints/multiuser-soundcards-pulseaudio For user Foo, the sound card sounds like it's dedicated for Foo. If this is the case the a udev rule should be written to ensure that only Foo has ACL rights on this file and any console-kit udev-acl callouts are ignored. That makes sense, thanks. I added that reply to the blueprint. For user Bar, I feel this is invalid. Why should user Bar have the right to output a sound any more than he has the right to display a popup window on my desktop? Here's another analogy; what about the printer? If printers were considered a part of the seat, then user Bar wouldn't have more right to print a document either. (The corresponding spy-on-mic analogy would be that someone puts a document in a scanner and another user scans it...) But printers are more of a system-wide resource, and for some use cases, so is the soundcard. And then, sharing makes sense. If another user is allowed to print a document while I'm logged in, why shouldn't he be able to play a sound? So would then the solution be to run PA as a system-wide daemon, and possibly assign soundcards to it via udev? If either scenario is to be supported, then what I suggested elsewhere in this thread is still valid I reckon. i.e something needs to be run as the active user that acts as an agent for some kind of (system?) service that actually generates said alarm. The agent will be running as the active user and it will be responsible for playing the sound/displaying the popup. Right, this would make sense for some use cases as well and worth considering. As for multi-seat, this is already in hand. Console-Kit has support for multi-seat stuff (tho' it may not be complete - I'm not overly sure here). What may still remain to be done is to tag certain devices as being for particular seats so that console-kit/udev can apply the appropriate ACLs when the set becomes active for a given user. All the multi-seat stuff is below PA tho' We'll just honour what it tells us. I don't think we don't need to add specific support for it. And the way ck/udev tells PA what devices it can use, is through device permissions? // David ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH] rtkit: Add client-side testing of properties
To complete the previous patch that implemented properties in rtkit,
here's the client-side code that tests that the properties work, and make
them more accessible for the casual C programmer.
// David
From 309659d47396544cd2b8d97ac5dac4460f543723 Mon Sep 17 00:00:00 2001
From: David Henningsson di...@ubuntu.com
Date: Sun, 7 Feb 2010 13:18:00 +0100
Subject: [PATCH] Implement client-side testing of property retrieval
---
rtkit-test.c | 22 ++--
rtkit.c | 114 ++
rtkit.h | 17 +
3 files changed, 150 insertions(+), 3 deletions(-)
diff --git a/rtkit-test.c b/rtkit-test.c
index 2841b52..9d2703f 100644
--- a/rtkit-test.c
+++ b/rtkit-test.c
@@ -76,7 +76,8 @@ static void print_status(const char *t) {
int main(int argc, char *argv[]) {
DBusError error;
DBusConnection *bus;
-int r;
+int r, r2;
+long long r3;
struct rlimit rlim;
dbus_error_init(error);
@@ -86,6 +87,21 @@ int main(int argc, char *argv[]) {
return 1;
}
+if ((r = rtkit_get_max_realtime_priority(bus)) 0)
+fprintf(stderr, Failed to retrieve max realtime priority: %s\n, strerror(-r));
+else
+printf(Max realtime priority is: %d\n, r);
+
+if ((r2 = rtkit_get_min_nice_level(bus, r)))
+fprintf(stderr, Failed to retrieve min nice level: %s\n, strerror(-r2));
+else
+printf(Min nice level is: %d\n, r);
+
+if ((r3 = rtkit_get_rttime_nsec_max(bus)) 0)
+fprintf(stderr, Failed to retrieve rttime limit: %s\n, strerror(-r3));
+else
+printf(Rttime limit is: %lld ns\n, r3);
+
memset(rlim, 0, sizeof(rlim));
rlim.rlim_cur = rlim.rlim_max = 1ULL; /* 100ms */
if ((setrlimit(RLIMIT_RTTIME, rlim) 0))
@@ -96,14 +112,14 @@ int main(int argc, char *argv[]) {
if ((r = rtkit_make_high_priority(bus, 0, -10)) 0)
fprintf(stderr, Failed to become high priority: %s\n, strerror(-r));
else
-printf(Sucessfully became high priority.\n);
+printf(Successfully became high priority.\n);
print_status(after high priority);
if ((r = rtkit_make_realtime(bus, 0, 10)) 0)
fprintf(stderr, Failed to become realtime: %s\n, strerror(-r));
else
-printf(Sucessfully became realtime.\n);
+printf(Successfully became realtime.\n);
print_status(after realtime);
diff --git a/rtkit.c b/rtkit.c
index aecc4e3..181f3de 100644
--- a/rtkit.c
+++ b/rtkit.c
@@ -2,6 +2,7 @@
/***
Copyright 2009 Lennart Poettering
+ Copyright 2010 David Henningsson di...@ubuntu.com
Permission is hereby granted, free of charge, to any person
obtaining a copy of this software and associated documentation files
@@ -56,6 +57,107 @@ static int translate_error(const char *name) {
return -EIO;
}
+
+static long long rtkit_get_int_property(DBusConnection *connection, const char* propname, long long* propval) {
+DBusMessage *m = NULL, *r = NULL;
+DBusMessageIter iter, subiter;
+dbus_int64_t i64;
+dbus_int32_t i32;
+DBusError error;
+int current_type;
+long long ret;
+const char * interfacestr = org.freedesktop.RealtimeKit1;
+
+dbus_error_init(error);
+
+if (!(m = dbus_message_new_method_call(
+ RTKIT_SERVICE_NAME,
+ RTKIT_OBJECT_PATH,
+ org.freedesktop.DBus.Properties,
+ Get))) {
+ret = -ENOMEM;
+goto finish;
+}
+
+if (!dbus_message_append_args(
+m,
+DBUS_TYPE_STRING, interfacestr,
+DBUS_TYPE_STRING, propname,
+DBUS_TYPE_INVALID)) {
+ret = -ENOMEM;
+goto finish;
+}
+
+if (!(r = dbus_connection_send_with_reply_and_block(connection, m, -1, error))) {
+ret = translate_error(error.name);
+goto finish;
+}
+
+if (dbus_set_error_from_message(error, r)) {
+ret = translate_error(error.name);
+goto finish;
+}
+
+ ret = -EBADMSG;
+dbus_message_iter_init(r, iter);
+while ((current_type = dbus_message_iter_get_arg_type (iter)) != DBUS_TYPE_INVALID) {
+if (current_type == DBUS_TYPE_VARIANT) {
+dbus_message_iter_recurse(iter, subiter);
+while ((current_type = dbus_message_iter_get_arg_type (subiter)) != DBUS_TYPE_INVALID) {
+if (current_type == DBUS_TYPE_INT32
