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
'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? 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 This would mean that if I do not have the jack plugged in, but I do have my USB speakers, then the sound would come out of the USB device, but when I plug in a 3.5mm jack to my built in speaker, the audio would switch to that. The above does have some fairly significant advantages (the above setup paints the use case quite clearly IMO). Of course if the priority lists are not exposed
[pulseaudio-discuss] [RFC] Source Output Volumes
Hello, As some of you know I've been working on restoring a little more symmetry to our API to allow the adjustment of source output (capture stream) volumes. In the past, when stream volumes were added to sink inputs, it was thought that this feature wouldn't be overly useful for capture streams and while this argument still holds true, there is one feature that has since been added to PA that would make it useful - flat volumes. Flat volumes allow for multiple streams to be connected to the same device and when they differ in stream volume, the maximum one is chosen and the h/w is set to that, with the difference in volume between the streams applied in software. This in theory allows for optimum power efficiency where the software stays out of the loop whenever possible. With flat volumes, adding per-stream volumes to capture streams makes sense. It does also simplify client code when they want to adjust their own volumes, they don't have to implement their own asymmetry to deal with ours. So I am proud to announce my work to try and achieve this. There are no doubt still bugs, so a thorough review is very much appreciated. I will not post patches to the list (unless screamed for) as some of them are necessarily rather large (+400 and +2k lines in the biggest patches). Most of the code is mirrored from the sink or sink input side. There is a lot of scope to cut down on code duplication but for the purposes of getting this out there I'll leave that for after the next release. In some cases, applying the patch and comparing e.g. sink.c with source.c is a better way of reviewing the changes (while there are still several differences it isn't too hard to compare them). I originally added support for synchronised streams for recording but then realised that this makes little sense practically and removed it again. I did the removal in a separate commit as it may be easier to compare the sink vs. source files before this patch to cut down on asymmetry) Known niggles; There are still some strange things with volumes. The flat volume stuff doesn't seem to work perfectly as when adjusting a recording stream volume down from NORM, the h/w volume does not drop... only when the hardware volume has been moved down to 0 and back to NORM does flat volume stuff work seem to work properly. I think there are still a few niggles with volume setting generally (for outputs too) as I still have a problem reported earlier that the initial volume of things is disconnected to the h/w state and while PA thinks it's got 100% it's actually not... I still need to look at that properly. So without further ado, here is the branch for review: http://colin.guthr.ie/git/pulseaudio/log/?h=master-source-volume git://colin.guthr.ie/pulseaudio (master-source-volume branch) For convenience of testing you can also use this patch to pavucontrol: http://colin.guthr.ie/git/pavucontrol/log/?h=master-source-volumes Have fun! Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCHv3 0/4] Read and store UCM data as proplist
'Twas brillig, and Jorge Eduardo Candelaria at 19/05/11 19:04 did gyre and gimble: I'm not trying to make it all just work atm, only provide a basis to continue working on and advance the discussion. Awesome! My previous mail was my polite way of saying it may not get committed just yet in it's current form but your reply tells me you fully appreciate that. I'll let discussions continue in other branches of this thread. Cheers Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Source Output Volumes
2011/5/20 Colin Guthrie gm...@colin.guthr.ie: Hello, As some of you know I've been working on restoring a little more symmetry to our API to allow the adjustment of source output (capture stream) volumes. In the past, when stream volumes were added to sink inputs, it was thought that this feature wouldn't be overly useful for capture streams and while this argument still holds true, there is one feature that has since been added to PA that would make it useful - flat volumes. Flat volumes allow for multiple streams to be connected to the same device and when they differ in stream volume, the maximum one is chosen and the h/w is set to that, with the difference in volume between the streams applied in software. This in theory allows for optimum power efficiency where the software stays out of the loop whenever possible. With flat volumes, adding per-stream volumes to capture streams makes sense. With these changes, would it still be possible to record audio without software gain? As it is now, I can record from a source that has its volume set to 100% and be confident that I'm getting the signal direct from the soundcard. Is that still the case with the default source output volume? Maarten It does also simplify client code when they want to adjust their own volumes, they don't have to implement their own asymmetry to deal with ours. So I am proud to announce my work to try and achieve this. There are no doubt still bugs, so a thorough review is very much appreciated. I will not post patches to the list (unless screamed for) as some of them are necessarily rather large (+400 and +2k lines in the biggest patches). Most of the code is mirrored from the sink or sink input side. There is a lot of scope to cut down on code duplication but for the purposes of getting this out there I'll leave that for after the next release. In some cases, applying the patch and comparing e.g. sink.c with source.c is a better way of reviewing the changes (while there are still several differences it isn't too hard to compare them). I originally added support for synchronised streams for recording but then realised that this makes little sense practically and removed it again. I did the removal in a separate commit as it may be easier to compare the sink vs. source files before this patch to cut down on asymmetry) Known niggles; There are still some strange things with volumes. The flat volume stuff doesn't seem to work perfectly as when adjusting a recording stream volume down from NORM, the h/w volume does not drop... only when the hardware volume has been moved down to 0 and back to NORM does flat volume stuff work seem to work properly. I think there are still a few niggles with volume setting generally (for outputs too) as I still have a problem reported earlier that the initial volume of things is disconnected to the h/w state and while PA thinks it's got 100% it's actually not... I still need to look at that properly. So without further ado, here is the branch for review: http://colin.guthr.ie/git/pulseaudio/log/?h=master-source-volume git://colin.guthr.ie/pulseaudio (master-source-volume branch) For convenience of testing you can also use this patch to pavucontrol: http://colin.guthr.ie/git/pavucontrol/log/?h=master-source-volumes Have fun! Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss ___ 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
Re: [pulseaudio-discuss] [RFC] Source Output Volumes
'Twas brillig, and Maarten Bosmans at 20/05/11 10:23 did gyre and gimble: With flat volumes, adding per-stream volumes to capture streams makes sense. With these changes, would it still be possible to record audio without software gain? As it is now, I can record from a source that has its volume set to 100% and be confident that I'm getting the signal direct from the soundcard. Is that still the case with the default source output volume? Yeah, that should still be the case. If you set the volume to of your stream to 100%, even if some other stream is recording at 50%, the h/w volume should be set to 100% Of course this is all rather arbitrary, as on my h/w the gain is 0dB when I set the volume to 0 at 100% it's +22.5dB, so to say direct from the sound card at 100% is a little strange it's getting +22.5dB :) I guess the problem would come when recording two things at once. If you set one to 100% (thus +22.5dB on my system) and one to the base volume of the source it's attached to (thus ALSA's 0dB*), then the one that expects to be recording at 0dB will actually get a signal that has gone up to +22.5dB and then come back down in software to 0dB. This isn't ideal, but then it's as non-ideal as it is currently and the use case for recording two streams at the same time is rather minimal anyway, so I don't think in all practicality, this is a big issue. Of course if you don't use flat volumes and only use per-stream recording volumes in your app, then the difference between the source volume and the stream volume does come into play AFAIUI. But then if you take the time to disable flat volumes, that's presumably a consequence you can live with. Col * I have one USB mic that reports it's range as +20dB to +50dB in alsa, so the base volume for it is actually significantly below the ALSA 0 point on the kcontrol! -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Source Output Volumes
2011/5/20 Colin Guthrie gm...@colin.guthr.ie: 'Twas brillig, and Maarten Bosmans at 20/05/11 10:23 did gyre and gimble: With flat volumes, adding per-stream volumes to capture streams makes sense. With these changes, would it still be possible to record audio without software gain? As it is now, I can record from a source that has its volume set to 100% and be confident that I'm getting the signal direct from the soundcard. Is that still the case with the default source output volume? Yeah, that should still be the case. If you set the volume to of your stream to 100%, even if some other stream is recording at 50%, the h/w volume should be set to 100% Of course this is all rather arbitrary, as on my h/w the gain is 0dB when I set the volume to 0 at 100% it's +22.5dB, so to say direct from the sound card at 100% is a little strange it's getting +22.5dB :) Ah, well I should probably have given some context. I'm recording from a 24bit/96Hz USB audio interface, so I want the PCM signal of the A/D converter as it is send over USB. This soundcard has no ALSA mixer element, so that part is easy. I just want to make sure Pulse doesn't do anything with that signal. I guess the problem would come when recording two things at once. If you set one to 100% (thus +22.5dB on my system) and one to the base volume of the source it's attached to (thus ALSA's 0dB*), then the one that expects to be recording at 0dB will actually get a signal that has gone up to +22.5dB and then come back down in software to 0dB. This isn't ideal, but then it's as non-ideal as it is currently and the use case for recording two streams at the same time is rather minimal anyway, so I don't think in all practicality, this is a big issue. Actually in my setup, I specifically put Pulse in the audio pipeline to be able to start multiple independent recordings simultaneously, without that requirement I could have just as well used ALSA directly (it's a headless audio server, not a desktop). The reason for this is that I want to be able to start a recording and separately decide whether the audio should be streamed (either RTP over LAN, or HTTP/Ogg/Vorbis over the internet, or both) and Pulse lets me start and stop the recording and live stream independently, which is great. Of course if you don't use flat volumes and only use per-stream recording volumes in your app, then the difference between the source volume and the stream volume does come into play AFAIUI. But then if you take the time to disable flat volumes, that's presumably a consequence you can live with. I have some experimenting to do with Pulse git, but I might very well end up disabling flat volumes, thanks for the hint. Col * I have one USB mic that reports it's range as +20dB to +50dB in alsa, so the base volume for it is actually significantly below the ALSA 0 point on the kcontrol! Maarten ___ 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
On May 19, 2011, at 3:11 PM, Tanu Kaskinen wrote:
I tried to apply the patch for easier review in meld, but unfortunately
it seems that some helpful software has eaten the first space on lines
that begin with one or more spaces. Because of that, git am doesn't
accept the patch.
I'll review this anyway, without meld.
Overall comments: there is some confusion about whether the jack stuff
is a core concept (hooks in pa_core) or an alsa specific thing (all jack
related type definitions are in alsa-jack.h). I think it probably makes
sense to keep alsa-jack.h as an alsa specific thing, but then the core
hooks shouldn't be tied to alsa-jack.h like they are now. In the longer
term I hope the thing how policy modules interact with jack detection
will be monitoring the (currently not existing) available status of the
port objects. However, if you don't want to start working on that now,
I'd just move alsa-jack.h under pulsecore (and of course rename it).
I think the best solution for now would be to move it to pulsecore.
The only major issue in my opinion is the jack_fd reading. It should be
made non-blocking.
--
Tanu
On Thu, 2011-05-19 at 11:44 -0500, Jorge Eduardo Candelaria wrote:
From: Margarita Olaya Cabrera m...@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 Cabrera m...@slimlogic.co.uk
Signed-off-by: Jorge Eduardo Candelaria j...@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
@@ -0,0 +1,42 @@
+#ifndef foopulsejackdetecthfoo
+#define foopulsejackdetecthfoo
+
+/***
+ This file is part of PulseAudio.
+
+ Copyright 2011 Wolfson Microelectronics PLC
+ Author Margarita Olaya m...@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.
+***/
+
+#include inttypes.h
+
+typedef enum pa_jack_event {
+PA_JACK_HEADPHONES,
+PA_JACK_HEADSET,
+PA_JACK_MICROPHONE,
+PA_JACK_LINEOUT,
+PA_JACK_UNKNOWN,
+PA_JACK_MAX
+} pa_jack_event_t;
+
+typedef struct pa_jack_detect {
+pa_jack_event_t event;
+char *card;
Instead of the card name, would it be better to store a pa_card pointer
here? It seems that you have the card object available when you
initialize this struct.
It seemed unnecessary since only the card name is being extracted from the
struct, but I get your point. I will change this.
+} pa_jack_detect_t;
Structs shouldn't have the _t suffix. (Enum typedefs should, so the
pa_jack_event_t name is correct.)
If this is alsa specific, like it seems to be, judging from the file
location and name, I recommend prefixing the types with pa_alsa_jack_,
because all other alsa stuff uses pa_alsa_ prefix too. Hmm... on the
other hand, this struct is passed to a core hook, so maybe these types
are not really alsa specific, and should be defined in a header under
src/pulsecore/?
Then these structs should defined the alsa-jack.h header, since it's going
to be moved to pulsecore.
Also, I think pa_jack_event would be a better name for what you've now
named pa_jack_detect, and the enum could be pa_jack_type_t.
Agreed, I will change this.
+#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
+++
[pulseaudio-discuss] How to redirect pulse audio through ssh?
Hi, I am currently trying to attempt to redirect pulse audio sound from a server to a client through ssh. I am bit unclear on what the correct way is of doing it. Some guides on the net refer to paprefs and some refer to socat and others again refer to loading modules via pactl. There is also something about using libpulse to get it automatically setup via X11 forwarding under ssh. I have tried different solutions without success so far. The server is running Ubuntu Linux 10.04 without a physical sound card installed. The client is running Maemo Linux Fremantle with a physical sound card installed. Client audio has been tested and confirmed working. paprefs does exist on the server but not on the client. Pulseaudio on the client seems not to be configured with per-user sessions. Pulseaudio on the server is configured for per-user sessions. The pulse socket on the client is on /var/run/pulse/native. The server's /etc/pulse/client.conf looks like this: - ; default-sink = ; default-source = ; default-server = ; autospawn = yes ; daemon-binary = /usr/bin/pulseaudio ; extra-arguments = --log-target=syslog ; cookie-file = ; enable-shm = yes ; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 MiB - One question: when modifying the pulse configuration via paprefs, what files does it modify? Anyways, what is the easiest method to get pulse audio on a server redirected to the client using ssh? qiet72 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] How to redirect pulse audio through ssh?
HI, Thanks for info, but I don't think it is the solution I am interested in. I have to use ssh as my server is behind a firewall and ssh is the only way to contact it. The other thing is I would like to use vnc to work with my server. Right now, I am doing this: client: ssh -L 5901:localhost:5901 user@server client: vncviewer localhost:5901 Of course vnc, does not support sound so I was hoping that I can use ssh tunnels to redirect the sound somehow. I did some xprop -root|grep PULSE tests. If I ssh to my server from an Ubuntu Linux machine, then I can see four PULSE variables in use. If I do the xprop test from Maemo Linux, then it shows no PULSE variables. If I ssh from there to my server with the -X parameter, then there is also no PULSE variables shown. I can confirm that pulseaudio is working on Maemo by doing a mplayer -ao pulse some-sound-file.wav br, Quinn On Fri, May 20, 2011 at 5:48 PM, Colin Guthrie gm...@colin.guthr.ie wrote: Hi, 'Twas brillig, and Quinn Plattel at 20/05/11 15:52 did gyre and gimble: I am currently trying to attempt to redirect pulse audio sound from a server to a client through ssh. I am bit unclear on what the correct way is of doing it. Firstly, I wrote up how our X11 piggy backing stuff work here: http://colin.guthr.ie/2009/08/sound-on-linux-is-confusing-defuzzing-part-2-pulseaudio/ Technically we do not tunnel over SSH directly (this can of course be done, but not automatically as SSH does not know about PA in the same way it knows about X11). We can however piggy back on the X11 forwarding built into SSH for our authentication (cookie) and server connection strings. If this is on a private network (direct routing) then the built in way is the best, but it doesn't go over SSH. You just need to ensure the machine you're sshing from has the netwrok protocol module loaded into PA (pactl load-module module-protocol-native-tcp, or put it in your default.pa) and make sure port 4713/tcp is open for external connections. Also ensure that module-x11-publish is loaded on the client side and you should get some interesting results from xprop -root | grep PULSE. Then when you ssh with x11 forwarding running the xprop command on the remote machine should show you the same results. If you cannot use the direct connection, just setup TCP tunnels in your SSH config and then hack the PULSE_SERVER property or env var on the remote machine to point to e.g. localhost:4713 which will actually be a tunnel back to localhost:4713 on the remote machine. The PULSE_COOKIE stuff already forwarded should be enough for auth. For debugging connections: PULSE_LOG=99 pactl stat This shows you e.g. the server name it's trying to connect to etc. Hope that helps (although I wrote it really quick so apologies if it doesn't! I'll clarify later if needs be :D) Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss -- Best regards/Med venlig hilsen, Quinn Plattel ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] How to redirect pulse audio through ssh?
Hi, This is interesting: client: ssh -XL 4713:localhost:4713 user@server server: PULSE_LOG=99 pactl stat Using shared memory pool with 1024 slots of size 64.0 KiB each, total size is 64.0 MiB, maximum usable slot size is 65472 Trying to connect to /home/quinn/.pulse/1ffe0fd6b5c9262aaa374e734c2cc8d0-runtime/native... SHM possible: yes Protocol version: remote 16, local 16 Negotiated SHM: yes Currently in use: 1 blocks containing 63.9 KiB bytes total. Allocated during whole lifetime: 15741 blocks containing 81.5 MiB bytes total. Sample cache size: 0 B User name: quinn Host Name: server Server Name: pulseaudio Server Version: 0.9.21-63-gd3efa-dirty Default Sample Specification: s16le 2ch 44100Hz Default Channel Map: front-left,front-right Default Sink: auto_null Default Source: auto_null.monitor Cookie: 6ccbf517 server: export PULSE_SERVER=localhost:4713 server: PULSE_LOG=99 pactl stat --- Using shared memory pool with 1024 slots of size 64.0 KiB each, total size is 64.0 MiB, maximum usable slot size is 65472 Trying to connect to localhost:4713... connect(): Connection refused Connection failure: Connection refused --- Ideas? Quinn On Fri, May 20, 2011 at 5:48 PM, Colin Guthrie gm...@colin.guthr.ie wrote: Hi, 'Twas brillig, and Quinn Plattel at 20/05/11 15:52 did gyre and gimble: I am currently trying to attempt to redirect pulse audio sound from a server to a client through ssh. I am bit unclear on what the correct way is of doing it. Firstly, I wrote up how our X11 piggy backing stuff work here: http://colin.guthr.ie/2009/08/sound-on-linux-is-confusing-defuzzing-part-2-pulseaudio/ Technically we do not tunnel over SSH directly (this can of course be done, but not automatically as SSH does not know about PA in the same way it knows about X11). We can however piggy back on the X11 forwarding built into SSH for our authentication (cookie) and server connection strings. If this is on a private network (direct routing) then the built in way is the best, but it doesn't go over SSH. You just need to ensure the machine you're sshing from has the netwrok protocol module loaded into PA (pactl load-module module-protocol-native-tcp, or put it in your default.pa) and make sure port 4713/tcp is open for external connections. Also ensure that module-x11-publish is loaded on the client side and you should get some interesting results from xprop -root | grep PULSE. Then when you ssh with x11 forwarding running the xprop command on the remote machine should show you the same results. If you cannot use the direct connection, just setup TCP tunnels in your SSH config and then hack the PULSE_SERVER property or env var on the remote machine to point to e.g. localhost:4713 which will actually be a tunnel back to localhost:4713 on the remote machine. The PULSE_COOKIE stuff already forwarded should be enough for auth. For debugging connections: PULSE_LOG=99 pactl stat This shows you e.g. the server name it's trying to connect to etc. Hope that helps (although I wrote it really quick so apologies if it doesn't! I'll clarify later if needs be :D) Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] How to redirect pulse audio through ssh?
Here is pactl stat on the client side: PULSE_LOG=99 pactl stat - Using private memory pool with 1024 slots of size 16,0 KiB each, total size is 16,0 MiB, maximum usable slot size is 16344 Trying to connect to /home/user/.pulse/fbd5d27658d3fcf30cb25bf800531799:runtime/native... connect(): No such file or directory (2) Trying to connect to /var/run/pulse/native... SHM possible: no Protocol version: remote 16, local 16 Negotiated SHM: no Currently in use: 1 blocks containing 16,0 KiB bytes total. Allocated during whole lifetime: 263989 blocks containing 231,3 MiB bytes total. Sample cache size: 0 B User name: pulse Host Name: Nokia-N900 Server Name: pulseaudio Server Version: 0.9.15 Default Sample Specification: s16le 2ch 48000Hz Default Channel Map: front-left,front-right Default Sink: sink.music Default Source: source.record Cookie: 26e54bb2 - br, Quinn On Fri, May 20, 2011 at 6:58 PM, Quinn Plattel qie...@gmail.com wrote: Hi, This is interesting: client: ssh -XL 4713:localhost:4713 user@server server: PULSE_LOG=99 pactl stat Using shared memory pool with 1024 slots of size 64.0 KiB each, total size is 64.0 MiB, maximum usable slot size is 65472 Trying to connect to /home/quinn/.pulse/1ffe0fd6b5c9262aaa374e734c2cc8d0-runtime/native... SHM possible: yes Protocol version: remote 16, local 16 Negotiated SHM: yes Currently in use: 1 blocks containing 63.9 KiB bytes total. Allocated during whole lifetime: 15741 blocks containing 81.5 MiB bytes total. Sample cache size: 0 B User name: quinn Host Name: server Server Name: pulseaudio Server Version: 0.9.21-63-gd3efa-dirty Default Sample Specification: s16le 2ch 44100Hz Default Channel Map: front-left,front-right Default Sink: auto_null Default Source: auto_null.monitor Cookie: 6ccbf517 server: export PULSE_SERVER=localhost:4713 server: PULSE_LOG=99 pactl stat --- Using shared memory pool with 1024 slots of size 64.0 KiB each, total size is 64.0 MiB, maximum usable slot size is 65472 Trying to connect to localhost:4713... connect(): Connection refused Connection failure: Connection refused --- Ideas? Quinn On Fri, May 20, 2011 at 5:48 PM, Colin Guthrie gm...@colin.guthr.iewrote: Hi, 'Twas brillig, and Quinn Plattel at 20/05/11 15:52 did gyre and gimble: I am currently trying to attempt to redirect pulse audio sound from a server to a client through ssh. I am bit unclear on what the correct way is of doing it. Firstly, I wrote up how our X11 piggy backing stuff work here: http://colin.guthr.ie/2009/08/sound-on-linux-is-confusing-defuzzing-part-2-pulseaudio/ Technically we do not tunnel over SSH directly (this can of course be done, but not automatically as SSH does not know about PA in the same way it knows about X11). We can however piggy back on the X11 forwarding built into SSH for our authentication (cookie) and server connection strings. If this is on a private network (direct routing) then the built in way is the best, but it doesn't go over SSH. You just need to ensure the machine you're sshing from has the netwrok protocol module loaded into PA (pactl load-module module-protocol-native-tcp, or put it in your default.pa) and make sure port 4713/tcp is open for external connections. Also ensure that module-x11-publish is loaded on the client side and you should get some interesting results from xprop -root | grep PULSE. Then when you ssh with x11 forwarding running the xprop command on the remote machine should show you the same results. If you cannot use the direct connection, just setup TCP tunnels in your SSH config and then hack the PULSE_SERVER property or env var on the remote machine to point to e.g. localhost:4713 which will actually be a tunnel back to localhost:4713 on the remote machine. The PULSE_COOKIE stuff already forwarded should be enough for auth. For debugging connections: PULSE_LOG=99 pactl stat This shows you e.g. the server name it's trying to connect to etc. Hope that helps (although I wrote it really quick so apologies if it doesn't! I'll clarify later if needs be :D) Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss -- Best regards/Med venlig hilsen, Quinn Plattel ___ pulseaudio-discuss mailing list
Re: [pulseaudio-discuss] How to redirect pulse audio through ssh?
Have you tried redirecting the port in SSH? Then you get the native PA with SSH. I am not sure if there is some standard port. Fred Frigerio On Fri, May 20, 2011 at 1:01 PM, Quinn Plattel qie...@gmail.com wrote: Here is pactl stat on the client side: PULSE_LOG=99 pactl stat - Using private memory pool with 1024 slots of size 16,0 KiB each, total size is 16,0 MiB, maximum usable slot size is 16344 Trying to connect to /home/user/.pulse/fbd5d27658d3fcf30cb25bf800531799:runtime/native... connect(): No such file or directory (2) Trying to connect to /var/run/pulse/native... SHM possible: no Protocol version: remote 16, local 16 Negotiated SHM: no Currently in use: 1 blocks containing 16,0 KiB bytes total. Allocated during whole lifetime: 263989 blocks containing 231,3 MiB bytes total. Sample cache size: 0 B User name: pulse Host Name: Nokia-N900 Server Name: pulseaudio Server Version: 0.9.15 Default Sample Specification: s16le 2ch 48000Hz Default Channel Map: front-left,front-right Default Sink: sink.music Default Source: source.record Cookie: 26e54bb2 - br, Quinn On Fri, May 20, 2011 at 6:58 PM, Quinn Plattel qie...@gmail.com wrote: Hi, This is interesting: client: ssh -XL 4713:localhost:4713 user@server server: PULSE_LOG=99 pactl stat Using shared memory pool with 1024 slots of size 64.0 KiB each, total size is 64.0 MiB, maximum usable slot size is 65472 Trying to connect to /home/quinn/.pulse/1ffe0fd6b5c9262aaa374e734c2cc8d0-runtime/native... SHM possible: yes Protocol version: remote 16, local 16 Negotiated SHM: yes Currently in use: 1 blocks containing 63.9 KiB bytes total. Allocated during whole lifetime: 15741 blocks containing 81.5 MiB bytes total. Sample cache size: 0 B User name: quinn Host Name: server Server Name: pulseaudio Server Version: 0.9.21-63-gd3efa-dirty Default Sample Specification: s16le 2ch 44100Hz Default Channel Map: front-left,front-right Default Sink: auto_null Default Source: auto_null.monitor Cookie: 6ccbf517 server: export PULSE_SERVER=localhost:4713 server: PULSE_LOG=99 pactl stat --- Using shared memory pool with 1024 slots of size 64.0 KiB each, total size is 64.0 MiB, maximum usable slot size is 65472 Trying to connect to localhost:4713... connect(): Connection refused Connection failure: Connection refused --- Ideas? Quinn On Fri, May 20, 2011 at 5:48 PM, Colin Guthrie gm...@colin.guthr.iewrote: Hi, 'Twas brillig, and Quinn Plattel at 20/05/11 15:52 did gyre and gimble: I am currently trying to attempt to redirect pulse audio sound from a server to a client through ssh. I am bit unclear on what the correct way is of doing it. Firstly, I wrote up how our X11 piggy backing stuff work here: http://colin.guthr.ie/2009/08/sound-on-linux-is-confusing-defuzzing-part-2-pulseaudio/ Technically we do not tunnel over SSH directly (this can of course be done, but not automatically as SSH does not know about PA in the same way it knows about X11). We can however piggy back on the X11 forwarding built into SSH for our authentication (cookie) and server connection strings. If this is on a private network (direct routing) then the built in way is the best, but it doesn't go over SSH. You just need to ensure the machine you're sshing from has the netwrok protocol module loaded into PA (pactl load-module module-protocol-native-tcp, or put it in your default.pa) and make sure port 4713/tcp is open for external connections. Also ensure that module-x11-publish is loaded on the client side and you should get some interesting results from xprop -root | grep PULSE. Then when you ssh with x11 forwarding running the xprop command on the remote machine should show you the same results. If you cannot use the direct connection, just setup TCP tunnels in your SSH config and then hack the PULSE_SERVER property or env var on the remote machine to point to e.g. localhost:4713 which will actually be a tunnel back to localhost:4713 on the remote machine. The PULSE_COOKIE stuff already forwarded should be enough for auth. For debugging connections: PULSE_LOG=99 pactl stat This shows you e.g. the server name it's trying to connect to etc. Hope that helps (although I wrote it really quick so apologies if it doesn't! I'll clarify later if needs be :D) Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list
[pulseaudio-discuss] Trying to make pulseaudio play audio using Ofono's HFP
I am trying to make Ofono's HFP implementation to work with my notebook and my cellphone (http://padovan.org/blog/2010/02/handsfree-profile-into- bluez-and-ofono/). Everything seems to work until playing the audio stream. Pulseaudio seems to receive the stream but it cannot play it and repeatly shows the messages below until it just terminates itself: D: module-loopback.c: Requesting rewind due to end of underrun. I: module- loopback.c: Coud not peek into queue Using the a2dp profile it plays the audio but termintes itself after some seconds showing a message that it was idle, but it was not idle, it was perfectly playing the audio when it decided to terminate itself. It also repeatly shows the message: D: memblock.c: Memory block too large for pool: 153600 65536 Pulseaudio's log for hfp is attached. I can attached the a2dp log too if necessary. -- Lamarque V. Souza http://www.geographicguide.com/brazil.htm Linux User #57137 - http://counter.li.org/ http://planetkde.org/pt-br pulseaudio_hfp.txt.gz Description: GNU Zip compressed data ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] Glitches on null sink?
Hi, I continue to develop my radio audio routing software so I continue to encounter strange bugs. General idea that lies behind my project is to split some processing parts into separate processes. There are many reasons why this architecture has to be like this, it something fundamental and won't change. For processing individual elements I use GStreamer (no external bindings, my code is in C). There're many advanced dedicated input sources, such as RTP/VoIP/shoutcast. All of them load their own null sink module, and perform output on one. Other modules that broadcast the signal to the FM/net just leech from their .monitor PA sources. To this moment everything works flawlessly, even if I load huge amount of sources. The problem is when I try to perform some audio processing or/and mixing. Currently I do that in the following way: 1. Load another null sink module for mix output. 2. Run GStreamer's pipelines (each is also a separate process), e.g.: a) pulsesrc device=source1.monitor ! processor1 ! processor2 ! pulsesink device=mix b) pulsesrc device=source2.monitor ! processor3 ! processor4 ! pulsesink device=mix It generally works ok, but from time to time, output (captured from mix.monitor) becomes full of glitches. Sounds like something lost synchronisation. And it's really hard to reproduce. Sometimes I run that kind of pipeline and it works for a long time and then it starts doing weird things, sometimes it starts it from the beginning. When it starts producing glitches, pulsesrc element in the GStreamer pipeline throws an error that it cannot read samples fast enough. What is interesting, when it starts doing that, any other audio that I pass to this mix sink also sounds bad from the begin. Only reloading module helps. My theory is that I have to use module-combine to perform such mixing. Am I correct? I wanted to avoid that as I am unable to dynamically add its slaves, but if it's the only way to perform such mix, I will do that, and reload it when my dedicated sources' list changes... It's not too pretty as it would produce short drops, but it's still acceptable. I just want you to ask if I am seeking for the problem in the correct place, just before I spend a week on refactoring my code. Maybe pipeline like shown above (pulseaudio - GStreamer - pulseaudio) also is a wrong approach? Thank you, m. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
