Re: [pulseaudio-discuss] [PATCH] module: new null-source module
On Wed, 2011-04-27 at 20:29 +0200, David Henningsson wrote: 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. I agree on simplification, but UCM actually removes a layer of complexity here as it abstracts numerous vendor/card specific Alsa mixer controls into pre-defined use cases. i.e. we no longer have to guess about whether device X has a control n1 or n2 or n2... to configure audio playback on headphones etc. Lets discuss this more in person next week ! 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? Yes, Maggies code is initial and basic support for UCM in pulseaudio. It's not intended to be full UCM support (this would take a lot longer) as it's really to get the ball rolling. 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. Liam ___ 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, 2011-04-12 at 21:58 +0100, Mark Brown wrote: 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. Yeah, this was one of the considerations here along with any OSS audio cards (as there are still a few OSS drivers upstream). This can be moved and integrated into module-alsa-card if desired ? Liam ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Alsa UCM integration.
On Fri, 2011-03-04 at 08:37 +0200, Tanu Kaskinen wrote: On Tue, 2011-03-01 at 15:20 +, Liam Girdwood wrote: UCM supports between 0..n active devices per verb. e.g. it is possible to enable both the headphone device and speaker device at the same time. Right, I missed this. But these multiple devices must share the PCM device, because there can be only one PCM device associated with a verb. Yes, devices 0..n will use the same PCM here. If we have verb+device pairs, how would we enable the Music verb and play to more than one device at the same time ? With modifiers that enable more devices. But yeah, since UCM supports defining multiple devices per verb as long as they use the same PCM device, it would be good if Pulseaudio would support this kind of configuration too. So, I hereby change my proposal: there would be one profile per verb, not per verb+device. This is then the same approach that Margarita started with :) If a verb has multiple devices defined for it, ports would be generated for the sink/source for each possible combination of those devices. Otherwise my proposal stays the same: modifiers are modeled using mappings or ports, depending on whether the modifier PCM device is different or the same that is already associated with some already existing mapping in the profile. Profiles will have to be changed so that mappings can be activated independently, without interrupting streams going to already activated mappings. Ok, make sense to me too. Thanks Liam ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Alsa UCM integration.
On Mon, 2011-02-28 at 22:34 +0200, Tanu Kaskinen wrote: On Sun, 2011-02-27 at 22:53 -0600, Margarita Olaya wrote: Hi Tanu, On Sat, Feb 26, 2011 at 2:07 AM, Tanu Kaskinen ta...@iki.fi wrote: On Fri, 2011-02-25 at 14:09 -0600, Margarita Olaya wrote: Make sense. But I am not sure the profiles as defined today in PulseAudio can work with modifiers. What we discussed yesterday is that when a profile is selected then you would set the UCM verb and know about all possible sinks. We would need additional logic to have profile modifiers, or we would need extra profiles to represent all possible combinations (speech, speech+tone, speech+music, etc). The initial idea is to use the UCM data to generate the card profiles, then when the stream is open PA will use his method to select the profile and set the verb. e.g when UCM is present: profile = verb. In the UCM module the data is store in a proplist per verb, the proplist has the following info: PA_PROP_UCM_SINK - PlaybackPCM PA_PROP_UCM_SOURCE - CapturePCM PA_PROP_UCM_PLAYBACK_VOLUME - PlaybackVolume PA_PROP_UCM_PLAYBACK_SWITCH - PlaybackSwitch PA_PROP_UCM_CAPTURE_VOLUME - CaptureVolume PA_PROP_UCM_CAPTURE_SWITCH - CaptureSwitch PA_PROP_UCM_QOS - TQ This means that there's only one sink and source per verb. That's probably ok, but if profile = verb, then this also means that there's only one sink and source per profile. Yes, this correct. What if one card has two playback devices - one for handsfree and one for a headset - and I want to play a ringtone to both simultaneously? What if one card has two playback devices - one for handset and one for TV-out - and I want to play music to the TV while a call is ongoing, and the call audio to the handset? I'm not saying that this kind of hardware exists, or that anyone actually wants to play music while having a call, but it would be nice if a solution would be found that would support also these cases. Hmm, I found now use-case.h via the link that you gave. That, together with your explanations, is making this more clear. Apparently those cases that I mentioned are supported by UCM via modifiers. So, if I've understood correctly, UCM dictates that there is always exactly one verb (main stream) and exactly one device (main device) selected per card. Additional streams and devices can be used by activating any number of modifiers. UCM supports between 0..n active devices per verb. e.g. it is possible to enable both the headphone device and speaker device at the same time. For example, if I wanted to play a ringtone to both the handsfree speaker and to a headset, I could select verb ringtone and device speaker, and then I'd activate modifier headset-ringtone, after which I could open the headset device in addition to the speaker device. In pulseaudio this would map to two sinks, and I'd use module-combine to play the ringtone to both. For another example, if I wanted to hear to music from the TV while talking to the phone, I could select the Voice Call verb and the Handset device, and then I'd activate modifier tv-music, after which I could open the TV-out device in addition to the handset device. Or since I probably was listening to the music before the call started, maybe I'd continue with the HiFi+TV-out combination and use a modifier for the call audio. My proposal is that profiles are generated for each available verb +device pair. I think the concept of a profile is going to need to be altered in some way to accommodate modifiers, because activating a modifier can enable a new PCM device (not always, though). A new PCM device means a new sink or source, but creating such sink or source needs to be possible without tearing down and recreating other sinks and sources of the profile, and that's not possible with current profiles. I propose that profiles stay as they are, with the difference that each sink and source of the profile can be enabled and disabled independently. The configuration defines which sinks and sources are activated by default. module-card-restore would remember user choices, though, so the defaults would be relevant only when the user hasn't done any changes, or when module-card-restore isn't used. (I don't think we actually need to have any UI for enabling and disabling the devices in a profile, at least initially, so for non-UCM configurations there wouldn't need to be any observable changes in behavior.) So, the verb+device pair would define the default sink and/or source that are always created when the profile is activated, and modifiers that have different PCM device than the device of the main use case would create additional devices to the profile. Modifiers that have the same PCM device as the main use case would add ports to the main use case sink and/or
Re: [pulseaudio-discuss] [RFC] Alsa UCM integration.
Sorry I couldn't make the meeting yesterday. On Thu, 2011-02-24 at 23:34 -0600, Margarita Olaya wrote: Pierre, On Thu, Feb 24, 2011 at 2:20 PM, pl bossart bossart.nos...@gmail.com wrote: The initial version of the UCM module is available at the following link: http://git.slimlogic.co.uk/cgi-bin/cgit.cgi/pulseaudio.git/log/?h=9.20-ucm_module I'm still working in the module, It is work in progress to verify the current verb when the stream is closed, also it is needed to add more code to work with the profiles and the use cases. Sink, source and device data could be taken from the proplist of the verb, and this is pending too. Hi Margarita, I looked at your patches and have the following comments: Thanks for the review and feedback on the meeting. - any reason why your version of PulseAudio is 1.3 years old. The previous patches on your branch are from 2009-11-18, quite a while ago. It'll make upstreaming difficult. Well, I had some troubles at the begging so I started by taking an stable rls but for sure I'll move soon the code to latest commit before upstream it. - you now have a separate module-alsa-ucm module, but it's called with a device name as a parameter. So if I have one USB headphone and one USB mic, this module will be called twice. It's not clear to me then how the virtual device would be handled, and how this is different from inserting all the code in module-alsa-card as you did it in your previous version? the idea was to have at least one card working, so yes this is pretty much the same approach than the code in module-alsa-card. Do you have any idea on how to manage virtual cards? I'm not clear on they way that ALSA manages virtual cards. - can you explain why you set the verb using the hook PA_CORE_HOOK_SINK_INPUT_NEW, with priority PA_HOOK_EARLY+15. There are other audio-policy related modules that may use different hooks, such as PA_CORE_HOOK_SINK_INPUT_PUT. I would think you want to set the verb at the UCM level after all this logic has made decisions, at the last possible moment before data start flowing. The initial approach was a bit different but after the IRC discussion I agree to use a different hook so verb will be set after all the analysis with profiles has been done but it is needed first to map a profile with a verb instead of the current approach with roles. - how do we make use of modifiers? I have not really thought about this. Modifiers can be used in the following situations:- 1) Music is being played. Pulseaudio has configured the Music use case verb via UCM. The system wants to play a tone, this could be a beep or even a ring tone for an incoming call. Pulseaudio would then check for a UCM play tone modifier for the current verb and then enable the modifier if it exists. This play tone modifier would setup the hardware to play both Music (i.e the verb) and additionally tones (the modifier). The modifier may use a different ALSA pcm and hardware volume controls to that of the main verb. If no play tone modifier exists then Pulsewould mix the tone into the music being played in software as it does atm. 2) Phone call is in progress. Pulseaudio has enabled the phone call UCM verb. The user wants to play music on the phone call. The modifier would be Music so Pulseaudio will check that a modifier exist for this when the phone call verb is active and enable this modifier. If no music modifier is available in the phone call verb configuration then pulseaudio would mix the music and voice in software. Liam ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Alsa UCM integration.
On Fri, 2011-02-25 at 10:10 -0600, pl bossart wrote: Modifiers can be used in the following situations:- 1) Music is being played. Pulseaudio has configured the Music use case verb via UCM. The system wants to play a tone, this could be a beep or even a ring tone for an incoming call. Pulseaudio would then check for a UCM play tone modifier for the current verb and then enable the modifier if it exists. This play tone modifier would setup the hardware to play both Music (i.e the verb) and additionally tones (the modifier). The modifier may use a different ALSA pcm and hardware volume controls to that of the main verb. If no play tone modifier exists then Pulsewould mix the tone into the music being played in software as it does atm. 2) Phone call is in progress. Pulseaudio has enabled the phone call UCM verb. The user wants to play music on the phone call. The modifier would be Music so Pulseaudio will check that a modifier exist for this when the phone call verb is active and enable this modifier. If no music modifier is available in the phone call verb configuration then pulseaudio would mix the music and voice in software. Make sense. But I am not sure the profiles as defined today in PulseAudio can work with modifiers. What we discussed yesterday is that when a profile is selected then you would set the UCM verb and know about all possible sinks. We would need additional logic to have profile modifiers, or we would need extra profiles to represent all possible combinations (speech, speech+tone, speech+music, etc). Yeah, I'm thinking it may be easier to add the extra profiles here. We could match a profile and it's UCM verb+modifier at init time. Liam ___ 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 Thu, 2010-04-29 at 17:38 -0500, pl bossart wrote: Howdy, When PulseAudio is used and all PCM is routed through PulseAudio (Fedora, Meego, etc), the notion of ALSA periods isn't very useful. PulseAudio uses a timer to refill buffers and the period interrupts are not used at all. So why not disable them entirely to reduce the number of wakeups? This is possible with a number of existing DMA controllers. The simple patch attached shows a proof-of-concept on HDAudio, it's been working for 5 hours on my Fedora12 laptop without any glitches and powertop does show _zero_ wakeups from the HDAudio controller (except on startup). I am told by my colleagues working in Windows environments that this is what's done on Vista/Windows7 btw. This isn't to say Windows is great but that artificial generation of not-needed interrupts is avoidable. There are probably some cases where you don't want this type of behavior (broken hardware, legacy code with multiple-buffering, disabled timer in PulseAudio), so I think it would make sense to request the disabling of interrupts when hw_params are set, since this is also the time when period sizes are set. I am aware that some changes would be needed in pcm_lib.c, where all the error checks are done. Takashi, Jaroslav, Lennart, what do you think? Feedback and suggestions welcome. Cheers - Pierre How do you handle any clock drift here between the HDA hardware interface clock and the PA timer ? Liam -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
