Re: [pulseaudio-discuss] [PATCH 1/2] alsa: add jack detection support
On Thu, May 26, 2011 at 01:07:33PM +0200, David Henningsson wrote:
On 2011-05-19 18:44, Jorge Eduardo Candelaria wrote:
+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.
The kernel does this by having separate statuses for headphone and
microphone and reporting them both for headset.
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Reverting ade0a6f88464d8aecf83982d400ccfc402341920
On Fri, May 13, 2011 at 10:11:55PM +0200, David Henningsson wrote: 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. Do you mean distortion or do you mean clipping? The general theory here is that there's no way to recover extra data from an input in the digital stages so you want to apply as much gain as possible in the analouge domain there. On output the reverse applies so you want to do any attenuation in the analogue domain so you get the maximum resolution from the DACs and attenuate their noise floor. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] rewind and underrun issues on start of playback
On Tue, May 03, 2011 at 11:09:56AM -0700, Baek Chang wrote: I think you are correct in that there is an alsa bug. It seems that pulseaudio 0.9.14 didn't exhibit this bug in the driver, but pulseaudio 0.9.22 does. It seems like the rewind is causing the driver to not have data in its first hw buffer, the dropout in the beginning is a hw buffer size. I frequently recommend PulseAudio as a test suite for driver DMA implementations :) ___ 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 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, 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. ___ 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 Wed, Apr 27, 2011 at 08:29:34PM +0200, David Henningsson wrote: On 2011-04-27 20:06, Mark Brown wrote: 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.) Meh, there's a reason I don't write userspace code :) The overall problem IMHO is that it is overly complex: 1) The kernel might set some basic volumes This is clearly going to happen if only as a function of the device having power on defaults - there's no might about it, there *will* be an initial state from the hardware but this should be consistent for every boot so not really any issue here. 2) Alsactl can store/restore volumes With UCM this shouldn't really happen (and if it does it should happen before UCM gets into play so the UCM configuration can just overwrite anything that happens). 3) Alsaucm can set volumes Not exactly, this should (unless I've gravely misunderstood the implementation, which is possible) be done by PulseAudio setting a use case with UCM. 4) PulseAudio (for the gdm user) can store/restore volumes 5) PulseAudio (for the logged on user) can store/restore volumes Presumably PulseAudio already gets the interface between these two right. The theory with UCM (again, assuming no massive misunderstandings of the final implementation on my part) is that when UCM is in play these volumes should be set using the volume controls that the UCM config told PulseAudio to use for the current use case and that PulseAudio should just ignore anything else. Setting the use case will both set most of the controls and tell PulseAudio which controls it should play with for runtime control, and whoever writes the use case configuration for a given system needs to make sure that those don't interfere with each other. 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. Hopefully the above clarifies; like I say, UCM configurations do have provision for telling the system audio daemon which controls it can play with. Only one thing, PulseAudio, should ever be applying configuration so there shouldn't be much problem with races. 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? Dunno, not checked. ___ 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 Wed, Apr 27, 2011 at 08:04:06PM +0100, Liam Girdwood wrote: On Wed, 2011-04-27 at 20:29 +0200, David Henningsson wrote: The patches basically provide the ability to :- 1) Store UCM verb and devices configuration in proplists. 2) Allow pulseaudio to change the UCM usecase verb and device. 3) Implement a jack sense module that listens for jack events. 4) Act on jack events to change UCM device. We should probably get 1 and 2 upstream first. I know she is working on something else atm and will probably be back to this in a few weeks time. I agree on this - apart from anything else if people are happy with the basic mechanics it'll save on review time of those bits. ___ 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 Tue, Apr 12, 2011 at 02:14:04PM -0500, pl bossart wrote: Jack detect does not use the ALSA kernel subsystem but does instead use the input subsystem for jack status. It makes sense to create a new module so we can then use jack detect for non ALSA sound devices. I'm a bit lost here. What are 'non ALSA sound devices'? And to the best of my knowledge these events are only generated by ALSA drivers... Am I missing something here? These events can be generated by anything - prior to my implementing the ALSA support for this all the implementations in mainline were doing this via the gpio-keys driver since they were detecting a microswitch in the jack. I'd expect that non-audio jacks may also end up reporting via the same interface (video for example), but I'm not sure if Pulse would be interested in anything non-ALSA. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Dynamic reconfiguration of sampling rate
On Wed, Jan 19, 2011 at 10:23:44AM -0600, pl bossart wrote: So I'm not sure we can idle@0s as a general rule, but as I have very limited test hardware (namely my laptop and couple other machine which aren't really meant for testing!), I can't really say this with any degree of confidence. I'll do more testing later today. I could see some issues with networking or interfaces like S/PDIF or HDMI, where the receiver needs to relock. But for local playback we should be fine. You will still Not always - anything which doesn't bias the outputs to zero volts (and even some things that do) is likely to have some pop/click or delay issues on powerup. Newer hardware will generally do better here but not everyone uses the latest shiny. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Dynamic reconfiguration of sampling rate
On Tue, Jan 18, 2011 at 12:16:33PM +, Colin Guthrie wrote: 'Twas brillig, and Mark Brown at 18/01/11 11:51 did gyre and gimble: If you play a new message notification over a movie then if the notification is an MP3 at 44.1kHz and the movie is at 48kHz you need SRC as well as mixing, and even on a phone you may want to route things to different sets of outputs simultaneously (eg, music to headphones and ringtone to headphones plus speaker). There's also the simple argument that if your hardware is capable of offloading some of the DSP work from the CPU more efficiently than the CPU can do it itself that's a win. Without wanting to fork this thread, I think the routing is separate from the SRC stuff (unless the hardware is suitably outsmarting us here!) There ends up being overlap in terms of implementation underneath - to a large extent what you're doing is breaking the signal path in software at some point prior to spitting out the final mixed stream and stuffing it into hardware. It's all done under software direction still, it's just the data path is getting offloaded. ___ 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 Thu, Dec 02, 2010 at 11:38:08AM +0100, David Henningsson wrote: 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? It's not going to make such an enormous difference if both are analogue, but in general each analogue amplification stage will introduce noise so you want to amplify as early as possible. If Capture is digital (which is possible) then it is vastly better to do the amplification in the boost stage as you've discarded data in the ADC with the signal at the low level it was at. 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. Well, someone can always set up use cases for their system if they want to. I'd expect Pulse to be able to DTRT with PC hardware without any of that most of the time, though. ___ 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 Wed, Dec 01, 2010 at 03:09:10PM +, Colin Guthrie wrote: 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 for stereo 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 the Rear playback so why do we do it on mics? As you can tell, my foo for recording is rather weak :D You might have more than two microphones built in to use them for beam forming applications in which case you're looking at a many channel array and do want everything in sync. On the other hand you may be doing something a lot less sophisticated and just have several sets of microphones for different physical use cases (eg, one set for use in tablet mode with the screen fully folded over and another for use in laptop mode) in which case you'd probably have only one in play at once. Or even some combination of the above :) ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] dynamically changing alsa sink/source sampling rate
On Tue, Nov 16, 2010 at 09:41:38PM -0800, Baek Chang wrote: Well say the client/user had a legitimate reason to switch the sampling rate (for example, low power usage or hw limitations for certain applications where it has to be a fixed sampling rate). Would it be possible to suspend all sink/sources, reconfigure the sink/source by changing the configuration, then unsuspend them. Pops and clicks can be minimized with the proper sequencing, not eliminated but made as silent as possible. In the embedded case we'll already be powering down the output when the stream is idle (and therefore reconfigurable) anyway. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Routing of audio to loudspeakers or headphones
On Fri, Aug 27, 2010 at 08:49:16AM +, Kim Therkelsen wrote: [Please fix your MUA to word wrap within paragraphs, it makes your messages vastly more legible.] No, DSP in kernel will never be accepted upstream. ALSA supports doing DSP at the application layer, though PulseAudio bypasses all the setup for that by default. I do not really understand what you mean by No, DSP in kernel will never be accepted upstream. Code which does signal processing on the CPU in kernel space will never be accepted by the ALSA developers. What I want is to make is a DSP module that improves the sound quality of the sound coming from the laptop builtin speakers by applying DSP Sure, this was clear. What I really want to know is: Where can I place this module: As a plugin to PulseAudio? Pulse should be able to do this. Some other type of plugin? You could do an ALSA plugin, though Pulse would require some persuasion to run with it. As a kernel module? This will not be accepted. In the audio driver? The audio drivers are mostly in kernel. My requirements: 1) Must be able to detect if headphones are connected Note that it's not just a case of checking if they're plugged in - you also need to check that the signal you're interested in is going via them. 2) Must be able to process stereo and multichannel (5.1/7.1) formats. I need the multichannel formats to perform my binaural downmixing to stereo. You want to be somewhere in application layer for all of this. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Routing of audio to loudspeakers or headphones
On Wed, Aug 25, 2010 at 03:49:44PM +0100, Colin Guthrie wrote: 'Twas brillig, and pl bossart at 25/08/10 14:31 did gyre and gimble: For jack sensing, we'd need a module that traps input events. ALSA sends an input event when the headphone jack is inserted. This is what's used in Meego (the detection isn't part of PulseAudio though). Yeah that's what is intended but I believe the general state of Jack Sensing is pretty busted generally It should be totally reliable where present for the embedded space, the issues are with HDA mostly. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Routing of audio to loudspeakers or headphones
On Wed, Aug 25, 2010 at 07:47:18AM +, Kim Therkelsen wrote: Do you think it would be possible and a good idea to make the DSP as a kernel module instead? I want the DSP module to be usable in different linux distributions - also those that do not use PulseAudio by default. No, DSP in kernel will never be accepted upstream. ALSA supports doing DSP at the application layer, though PulseAudio bypasses all the setup for that by default. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] porting pulse audio to Android
On Thu, Jul 22, 2010 at 12:33:01PM +0100, Colin Guthrie wrote: 'Twas brillig, and priyanka sharma at 22/07/10 12:18 did gyre and gimble: I need some help in understanding the amount of effort required to port Pulse Audio to Android. Any help in this regard would be of great use to us. As far as the compilation etc. it shouldn't be too hard, but from what I understand the current reason PA is not on Android is purely from a licensing perspective. I believe the only GPL'ish code that is permitted as part of the official android stack is the kernel itself. Just to clarify, there's no problem with handset vendors including GPLed code if they want to (barring any licensing conflcits with other software on the device) - the concerns purely surround what is included by default as part of the Android platform release. I guess then the problems would be with how android apps interact with audio? I'm not sure how they actually do their output or input? I believe there is a separate lib on andoird for this (I don't know the details but others on this list do so can maybe advise better) but perhaps it can be adapted to work with PA rather than plain alsa? The high level architecture is this: http://source.android.com/porting/audio.html You'd end up tweaking an off the shelf ALSA libaudio to bounce via Pulse, possibly bypassing the ALSA abstractions and talking directly to Pulse for the data injection as well as using Pulse to configure any soft routing it does. Hopefully someone can chip in with more details of how hard the porting would be from a wider picture perspective. Should be fairly straightforward to get it working. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Changing default soundcard on attach/detach of soundcards
On Fri, Jul 16, 2010 at 11:41:33AM -0500, pl bossart wrote: Well right now there are several projects (outside of my own) going on in this field, but there does seem to be a little bit of disparity with upstream people. One project specifically is coming from the ALSA side and will get support in PA. This project is very likely to become the defacto method of operation on embedded systems and thus I would hope that people at MeeGo would talk more openly about what they are doing so as not to reinvent the wheel. If you are talking about the audio scenarios developed by Liam, I don't think there's any sort of conflict. it's my understanding that the scenarios are mainly to configure the hardware routing and performance of a given audio device using specific settings (eg voice volume, etc). This thread is more about what output will be used if you have multiple audio accessories or peripherals. It's one level higher I guess. I missed the start of this discussion so I'm missing some context here but there may actually quite a bit of overlap here - on systems like smartphones it's very common for all the audio to be a single integrated subsystem with multiple paths through it and the CPU as only one node in that system. Things like Bluetooth headsets wouldn't appear as a separate sound card, they'd appear as an output option on the existing sound card, and many audio paths will be connected directly through the hardware without entering the PulseAudio domain. Since there can be multiple paths through the system you can also end up with different streams on the CPU being routed separately - the classic example is having an MP3 playing to headphones and simultaneously ringtone/alert sounds routed to both headphones and speaker. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [alsa-devel] [RFC] disabling ALSA period interrupts
On Wed, May 12, 2010 at 08:50:42AM -0500, pl bossart wrote: This might be almost equivalent to the timer approach in terms of # of wakeups, however the timer can be reprogrammed on-the-fly whereas periods can only be changed by closing and reopening the device. You can also adjust the timer shall underflows occur. And the timer slack lets the kernel group events. Not to mention that you will need The timer is also useful for allowing PulseAudio to dynamically adjust the period size as the runtime situation changes - if you're running high latency streams and have a low latency application start up then PulseAudio can just change the timer to get more frequent events. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] sample-rate changes in module-rtp-recv
On Mon, Apr 05, 2010 at 02:23:50PM -0500, pl bossart wrote: Ideally we should enforce a stronger smoothing on the time estimation, there's no reason why such variations should occur. I forced the smoothing history to 20s, maybe there's a better way to do this. FWIW a lot of impleementations seem to struggle to keep track of time properly over silence periods so it's worth resetting things whenever you get one. Adapting the jitter buffer depth rather than the sample rate also helps if the source is having difficulty - it can be due to network issues, and this does absorb changes up and down without needing to be too smart. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
