Re: [pulseaudio-discuss] [PATCH 0/5] HW and SW volume syncronization in IO-thread
On 2010-10-13 18:40, o...@iki.fi wrote: From: Jyri Sarhajyri.sa...@nokia.com The first patch in the set gives sink implementor a possibility to synchronize HW and SW volume usage in IO-thread. The remaining patches implement the synchronization for the alsa-sink and add the necessary module parameters and defaults for them in daemon configuration. This code has been tested on Nokia's ARM based Meego platform, on i686 laptop and on amd64 desktop. Tanu Kaskinen has also reviewed the code. To check what this set of patches does, please try following: 1. play white noise in background on low volume: # pacat --fix-rate --volume=1 /dev/urandom 2. play a short transient stream with high volume while the noise plays in background: # dd if=/dev/zero count=200 | pacat --fix-rate --volume=65536 Without these patches on most hardware you hear an annoying snap either in the beginning or the end (sometimes both) of the transient stream.After applying the patch the snap should be gone or at least less audible. With a little fiddling of the parameters it should be possible to get rid of the snap on all hardware. The default parameters work well at least on my Lenovo T60 running Debian Squeeze and they should be good, maybe a bit conservative, for most HW out there. This patch is pretty much mandatory for proper usage of flat volume especially on less powerful HW. Thank you for your work! This is the main reason I've been advocating against enabling flat-volumes by default in Ubuntu, so I'm glad to see something that addresses the issue. The basic problem is that we can't have sample accurate volume changes, because no HW supports it. Right? So about the implementation - what you're saying is that it is better to have two guaranteed down-volume snaps rather than to risk an up-volume snap. That sounds reasonable, but are these down-volume transients hearable? Perhaps more hearable with playing a sine wave, rather than white noise? Anyway, I've been thinking of something like this but never looked more closely at implementing a solution, but I would probably have tried to do something like: start: 1) rewind 2) write stream with lower SW volume 3) wait until rewind margin has passed 4) raise HW volume end: 1) lower HW volume 2) rewind 3) write stream with higher SW volume ...rather than trying to add explicit delays just for the volume sync. Either that, or some kind of volume ramping. Just curious if you considered that solution as well? -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] Wanted: native English speakers for review: [PATCH 5/5] man: sync_volume parameters to manual page
Am Mittwoch, den 13.10.2010, 19:40 +0300 schrieb o...@iki.fi: From: Jyri Sarha jyri.sa...@nokia.com Signed-off-by: Jyri Sarha jyri.sa...@nokia.com Reviewed-by: Tanu Kaskinen tanu.kaski...@digia.com It would be great if some native English speakers could take a look at the following sentences. Maybe David (CCed) has some time too. I am giving it a shot too, but I do not know if everything is correct. --- man/pulse-daemon.conf.5.xml.in | 26 ++ 1 files changed, 26 insertions(+), 0 deletions(-) diff --git a/man/pulse-daemon.conf.5.xml.in b/man/pulse-daemon.conf.5.xml.in index b5c9e92..ccc2db7 100644 --- a/man/pulse-daemon.conf.5.xml.in +++ b/man/pulse-daemon.conf.5.xml.in @@ -437,6 +437,32 @@ USA. /section + section name=Default Sync Volume Settings + +pThe flat volume feature sets the sink HW volume according to according to *the* +highest volume input stream and lowers the lower volume streams +with SW volume. To make this concurrent use of SW and HW volume to +work without a glitch their application needs to be +synchronized. The sink implementation needs to support this +feature in order to these parameters to take effect./p + +option + poptenable-sync-volume=/opt Enable sync volume for the sinks that + support it. This feature is enabled by default./p +/option +option + poptsync-volume-safety-margin-usec=/opt The amount usecs the HW amount *of* usecs + volume increases are delayed and HW volume decreases are advanced. Defaults As someone who does not have a clue, could that be a little bit more elaborate explained. Why should increases be delayed? Could an example be give and would it be useful? + to 8000 usec./p +/option +option + poptsync-volume-extra-delay-usec=/opt The amount usecs the The amount *of* usesc + all HW volume changes are delayed. Negative values are also allowed. »the all«? + Defaults to 0./p +/option + + /section + section name=Authors pThe PulseAudio Developers lt;@PACKAGE_BUGREPORT@gt;; PulseAudio is available from url href=@PACKAGE_URL@//p /section Thanks, Paul signature.asc Description: This is a digitally signed message part ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Wanted: native English speakers for review: [PATCH 5/5] man: sync_volume parameters to manual page
--- On Thu, 14/10/10, Paul Menzel paulepan...@users.sourceforge.net wrote: The amount *of* usesc The number of usecs would be better. PeterO ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] AC3 passthrough support
To use this feature from other frameworks (gstreamer, etc), we will need a tagged release to #ifdef code related to AC3 passthough for backwards compatibility. Any idea when that might happen? (would also be nice to close the gap between git master and meego versions while we are at it...) What's the status on this? Is it usable and #ifdef able? This would be damn good news for us (xbmc). /Joakim ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 0/5] HW and SW volume syncronization in IO-thread
On 2010-10-13 18:40, o...@iki.fi wrote: From: Jyri Sarhajyri.sa...@nokia.com ... Thank you for your work! This is the main reason I've been advocating against enabling flat-volumes by default in Ubuntu, so I'm glad to see something that addresses the issue. The basic problem is that we can't have sample accurate volume changes, because no HW supports it. Right? Yes. On on non real-time OS and having less than accurate audio pipeline latency information this is a best effort task. Making this perfect would require HW support. So about the implementation - what you're saying is that it is better to have two guaranteed down-volume snaps rather than to risk an up-volume snap. That sounds reasonable, but are these down-volume transients hearable? Perhaps more hearable with playing a sine wave, rather than white noise? Since implementing ramps on a HW mixer is really not applicable, this is the only solution that I can see and in practice it seems to work pretty well. I also think that most analog components have enough slowness in them which in effect causes a kind of ramp. BTW, ran the test from my previous mail, but using sine wave, and still I could not hear any snapping sound on my T60. Anyway, I've been thinking of something like this but never looked more closely at implementing a solution, but I would probably have tried to do something like: start: 1) rewind 2) write stream with lower SW volume 3) wait until rewind margin has passed 4) raise HW volume This is pretty much what my patch is doing, just in slightly different order: 1. Insert volume event to happen after sink's reported latency has expired (+ modifications). 2. rewind and adjust volume events 3. wait until volume event expires = rewind margin has passed 4. raise HW volume This approach works also with sinks that do not support rewinding (e.g. alsa-sink not using tsched). end: 1) lower HW volume 2) rewind 3) write stream with higher SW volume Here you are forgetting that there may still be some samples left within the rewind margin. You should add the delay also there. In effect the both volume ups and downs become quite symmetrical. ...rather than trying to add explicit delays just for the volume sync. Either that, or some kind of volume ramping. Just curious if you considered that solution as well? Well, I can't think how you get past wait until rewind margin has passed without having explicit delays. This code is really only chaning the way HW mixers are used. Ramping to SW volume could be implemented separately and it would not interfere with this patch in fact they would complement each other. But, hey please try out my patch. At least it solved the problem on N900 (yes the earlier version of the patch is on all N900s out there) and it works quite well on my both Linux boxes. Cheers, Jyri ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 0/5] HW and SW volume syncronization in IO-thread
On 2010-10-13 18:40, o...@iki.fi wrote: From: Jyri Sarhajyri.sa...@nokia.com ... ...rather than trying to add explicit delays just for the volume sync. Either that, or some kind of volume ramping. Just curious if you considered that solution as well? Ah, only after reading my reply from the mailing list I understand your concern. The sync-volume is really not only using some explicit timers, but it uses sinks latency information (got with pa_sink_get_latency_within_thread()) for timing the HW volume changes and adjust the timers when ever the DMA buffer is rewound. The parameters given are there only to compensate for timer and reported latency inaccuracy. The safety margin is for compensation dynamic inaccuracy and extra delay is there to compensate static errors. On most hardware extra delay should be set to zero. Cheers, Jyri ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 0/5] HW and SW volume syncronization in IO-thread
On 2010-10-13 18:40, o...@iki.fi wrote: From: Jyri Sarhajyri.sa...@nokia.com ... Thank you for your work! This is the main reason I've been advocating against enabling flat-volumes by default in Ubuntu, so I'm glad to see something that addresses the issue. The basic problem is that we can't have sample accurate volume changes, because no HW supports it. Right? Yes. On on non real-time OS and having less than accurate audio pipeline latency information this is a best effort task. Making this perfect would require HW support. So about the implementation - what you're saying is that it is better to have two guaranteed down-volume snaps rather than to risk an up-volume snap. That sounds reasonable, but are these down-volume transients hearable? Perhaps more hearable with playing a sine wave, rather than white noise? Since implementing ramps on a HW mixer is really not applicable, this is the only solution that I can see and in practice it seems to work pretty well. I also think that most analog components have enough slowness in them which in effect causes a kind of ramp. BTW, ran the test from my previous mail, but using sine wave, and still I could not hear any snapping sound on my T60. Anyway, I've been thinking of something like this but never looked more closely at implementing a solution, but I would probably have tried to do something like: start: 1) rewind 2) write stream with lower SW volume 3) wait until rewind margin has passed 4) raise HW volume This is pretty much what my patch is doing, just in slightly different order: 1. Insert volume event to happen after sink's reported latency has expired (+ modifications). 2. rewind and adjust volume events 3. wait until volume event expires = rewind margin has passed 4. raise HW volume This approach works also with sinks that do not support rewinding (e.g. alsa-sink not using tsched). end: 1) lower HW volume 2) rewind 3) write stream with higher SW volume Here you are forgetting that there may still be some samples left within the rewind margin. You should add the delay also there. In effect the both volume ups and downs become quite symmetrical. ...rather than trying to add explicit delays just for the volume sync. Either that, or some kind of volume ramping. Just curious if you considered that solution as well? Well, I can't think how you get past wait until rewind margin has passed without having explicit delays. This code is really only chaning the way HW mixers are used. Ramping to SW volume could be implemented separately and it would not interfere with this patch in fact they would complement each other. But, hey please try out my patch. At least it solved the problem on N900 (yes the earlier version of the patch is on all N900s out there) and it works quite well on my both Linux boxes. Cheers, Jyri ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 0/5] HW and SW volume syncronization in IO-thread
On 2010-10-13 18:40, o...@iki.fi wrote: From: Jyri Sarhajyri.sa...@nokia.com ... ...rather than trying to add explicit delays just for the volume sync. Either that, or some kind of volume ramping. Just curious if you considered that solution as well? Ah, only after reading my reply from the mailing list I understand your concern. The sync-volume is really not only using some explicit timers, but it uses sinks latency information (got with pa_sink_get_latency_within_thread()) for timing the HW volume changes and adjust the timers when ever the DMA buffer is rewound. The parameters given are there only to compensate for timer and reported latency inaccuracy. The safety margin is for compensation dynamic inaccuracy and extra delay is there to compensate static errors. On most hardware extra delay should be set to zero. Cheers, Jyri ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] AC3 passthrough support
To use this feature from other frameworks (gstreamer, etc), we will need a tagged release to #ifdef code related to AC3 passthough for backwards compatibility. Any idea when that might happen? (would also be nice to close the gap between git master and meego versions while we are at it...) What's the status on this? Is it usable and #ifdef able? This would be damn good news for us (xbmc). I am planning some changes to the existing patch. The current solution only uses a 'passthrough' flag, but you would need additional information to pass format information so that you can pass MP3 to play over BT headset, or AC3 over HDMI. Today this isn't possible with a boolean only. I am not familiar at al with XBMC, if you have specific requirements or ideas, they are welcome at this point. I only looked at the problem from a gstreamer perspective. The main idea so far is to try and use the passthrough mode, and if the connection fails (no support in hardware or audio policy), then you would fall back to software decode. -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC - MP3 passthrough over A2DP 1/2] mp3 passthrough: core changes
Hi There's no real way you can extract timing information just by looking at the data. You either need to parse the frames (what I did for the BT work) or let the hardware report the number of samples it decoded and rendered. In both cases, you could find out what the average bit rate is and have an approximate idea of the relationship between the numbers of bytes passed to pulseaudio and the duration. It would be a bad idea though to rely on this approximated bitrate to infer timing. The client should get the audio time as reported by this sample count, not through inversion of an approximation that will only be correct for constant bit rates. Instead of basing all time ports on GET_LATENCY messages we should really have a new GET_TIME message. Why can't the encoded data for MP3 be handled the same way as DTS/AC3 over spdif/hdmi? They are preformatted with a iec958 header and padded with zeroes to the correct sample length given samplerate and channel count. To padding and adding of this header is up to the application. Now if a2dp supports mp3 as a raw format can't the a2dp code in bluez or whatever is communicating with the a2dp device strip the header. This way timing through pulse remains simple.. /Joakim ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] AC3 passthrough support
'Twas brillig, and Joakim Plate at 14/10/10 13:40 did gyre and gimble: To use this feature from other frameworks (gstreamer, etc), we will need a tagged release to #ifdef code related to AC3 passthough for backwards compatibility. Any idea when that might happen? (would also be nice to close the gap between git master and meego versions while we are at it...) What's the status on this? Is it usable and #ifdef able? This would be damn good news for us (xbmc). Hi Joakim, FWIW, I'm an XBMC user and very much appreciate as a bit of software - big fan (especially as the beginnings of MythTV PVR support were added the other day :D) For my audio setup I actually use the ALSA output in 5.1 channel mode. It talks to pulse and then I setup the a52 based digital 5.1 output over SPDIF in PA. This is clearly suboptimal for the movies where passthrough would be preferred, but it's a very desirable solution as things stand right now. What would be great is if the direct PA output could use 5.1 channels more effectively than it does just now and that would mean I could stop pushing things through ALSA. (I may have to double check my setup as I've not looked at it for a while, but IIRC last time I tried direct PA output support it downmixed to 2ch in XBMC before hitting PA which then upmixed to 5.1) Anyway, I'd be very happy to discuss both the short and longer term approach for this with you either here or on #pulseaudio or #xbmc-linux (I am in both). Take care 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] Wanted: native English speakers for review: [PATCH 5/5] man: sync_volume parameters to manual page
'Twas brillig, and PETER ONION at 14/10/10 12:42 did gyre and gimble: --- On Thu, 14/10/10, Paul Menzel paulepan...@users.sourceforge.net wrote: The amount *of* usesc The number of usecs would be better. I've tweaked the wording in my local application of this patch. I went for The unit of time in the end as it read better. If you can't work out it's in usecs from the argument name then you really aren't qualified to be editing config files :p Other previously mentioned wording tweaks are incorporated too. 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] [PATCH 1/5] core: Add infrastructure for synchronizing HW and SW volume changes
Hi,
Review below:
'Twas brillig, and o...@iki.fi at 13/10/10 17:40 did gyre and gimble:
+PA_SINK_SYNC_VOLUME = 0x0200U,
+/** The HW volume changes are syncronized with SW volume.
+ * \since X.X.XX */
+
} pa_sink_flags_t;
Can you put 0.9.22 here? If needed I'll do a global find and replace on
any \since 0.9.22's if/when we release that version from stable queue
instead, but I'll almost certainly forget to fix up x.x.xx replacements.
diff --git a/src/pulsecore/sink.c b/src/pulsecore/sink.c
index ff4cc17..0f2af4f 100644
--- a/src/pulsecore/sink.c
+++ b/src/pulsecore/sink.c
+struct sink_message_set_port {
+pa_device_port *port;
+int ret;
+};
+
I'll refer to this below[1]
@@ -1459,7 +1493,8 @@ void pa_sink_set_volume(
* apply one to s-soft_volume */
pa_cvolume_reset(s-soft_volume, s-sample_spec.channels);
-s-set_volume(s);
+if (!(s-flags PA_SINK_SYNC_VOLUME))
+s-set_volume(s);
} else
/* If we have no function set_volume(), then the soft volume
Hmm, should this if have an else that sets send_msg to TRUE
(send_msg is used just below where the context ends) otherwise if
send_msg is set to false, then the message will not be pushed to the
asyncq and thus the set_volume() function will never be called in
pa_sink_process_msg()[2]
@@ -1474,18 +1509,22 @@ void pa_sink_set_volume(
pa_subscription_post(s-core,
PA_SUBSCRIPTION_EVENT_SINK|PA_SUBSCRIPTION_EVENT_CHANGE, s-index);
}
-/* Called from main thread. Only to be called by sink implementor */
+/* Called from the io thread if sync volume is used, otherwise from the main
thread.
+ * Only to be called by sink implementor */
void pa_sink_set_soft_volume(pa_sink *s, const pa_cvolume *volume) {
pa_sink_assert_ref(s);
-pa_assert_ctl_context();
+if (s-flags PA_SINK_SYNC_VOLUME)
+pa_sink_assert_io_context(s);
+else
+pa_assert_ctl_context();
if (!volume)
pa_cvolume_reset(s-soft_volume, s-sample_spec.channels);
else
s-soft_volume = *volume;
-if (PA_SINK_IS_LINKED(s-state))
-pa_assert_se(pa_asyncmsgq_send(s-asyncmsgq, PA_MSGOBJECT(s),
PA_SINK_MESSAGE_SET_VOLUME, NULL, 0, NULL) == 0);
+if (PA_SINK_IS_LINKED(s-state) !(s-flags PA_SINK_SYNC_VOLUME))
+pa_assert_se(pa_asyncmsgq_send(s-asyncmsgq, PA_MSGOBJECT(s),
PA_SINK_MESSAGE_SET_SOFT_VOLUME, NULL, 0, NULL) == 0);
else
s-thread_info.soft_volume = s-soft_volume;
}
This is a little concerning. If I have a sink (e.g. an roap-sink) whcih
does not support PA_SINK_SYNC_VOLUME flag, then you are now sending me a
different message to the one I got before.
While there is nothing in the tree that does this, there may be external
uses of this in private trees and I don't think there is any need to
change the semantics of PA_SINK_MESSAGE_SET_VOLUME.
Would it be better to instead define:
PA_SINK_MESSAGE_SET_VOLUME_SYNCED to go before
PA_SINK_MESSAGE_SET_VOLUME, and not change the message here and instead
change the o-process_msg() calls that use PA_SINK_MESSAGE_SET_VOLUME to
use PA_SINK_MESSAGE_SET_VOLUME_SYNCED?
I think this would be semantically the same with regards to your
requirements and keeps any out-of-tree reliance on
PA_SINK_MESSAGE_SET_VOLUME message semantically unchanged.[3]
@@ -1555,6 +1594,16 @@ static void propagate_real_volume(pa_sink *s, const
pa_cvolume *old_real_volume)
pa_subscription_post(s-core,
PA_SUBSCRIPTION_EVENT_SINK|PA_SUBSCRIPTION_EVENT_CHANGE, s-index);
}
+/* Called from io thread */
+void pa_sink_update_volume_and_mute(pa_sink *s) {
+pa_assert(s);
+pa_sink_assert_io_context(s);
+
+pa_asyncmsgq_post(pa_thread_mq_get()-outq, PA_MSGOBJECT(s),
+ PA_SINK_MESSAGE_UPDATE_VOLUME_AND_MUTE,
+ NULL, 0, NULL, NULL);
+}
+
While the limiting of line length is appreciated, I think most of the
other calls are just long lines... so probably worth leaving it on one
line for consistency.
@@ -1605,7 +1654,7 @@ void pa_sink_set_mute(pa_sink *s, pa_bool_t mute,
pa_bool_t save) {
+if (!(s-flags PA_SINK_SYNC_VOLUME) s-set_mute)
@@ -1624,7 +1673,7 @@ pa_bool_t pa_sink_get_mute(pa_sink *s, pa_bool_t
force_refresh) {
+if (!(s-flags PA_SINK_SYNC_VOLUME) s-get_mute)
These two, as above.
@@ -2000,6 +2049,14 @@ int pa_sink_process_msg(pa_msgobject *o, int code,
void *userdata, int64_t offse
case PA_SINK_MESSAGE_SET_VOLUME:
+if (s-flags PA_SINK_SYNC_VOLUME) {
+s-set_volume(s);
+pa_sink_volume_change_push(s);
+}
+/* Fall through ... */
[2]: Just for reference, here is where the above could result in
s-set_volume() not being called.
@@ -2127,6 +2204,21 @@ int pa_sink_process_msg(pa_msgobject *o, int code,
void *userdata, int64_t offse
Re: [pulseaudio-discuss] [PATCH 2/5] alsa: Take syncronized HW volume infra into use for alsa-sink
Hi,
Review below:
'Twas brillig, and o...@iki.fi at 13/10/10 17:40 did gyre and gimble:
diff --git a/src/modules/alsa/alsa-sink.c b/src/modules/alsa/alsa-sink.c
index 1108a79..ada5da9 100644
--- a/src/modules/alsa/alsa-sink.c
+++ b/src/modules/alsa/alsa-sink.c
@@ -1651,8 +1713,15 @@ static int setup_mixer(struct userdata *u, pa_bool_t
ignore_dB) {
u-sink-get_volume = sink_get_volume_cb;
u-sink-set_volume = sink_set_volume_cb;
+u-sink-write_volume = sink_write_volume_cb;
+
+if (sync_volume) {
+u-sink-flags |= PA_SINK_HW_VOLUME_CTRL |
+(u-mixer_path-has_dB ? (PA_SINK_DECIBEL_VOLUME |
PA_SINK_SYNC_VOLUME) : 0);
+pa_log_info(Successfully enabled synchronous volume.);
+} else
+u-sink-flags |= PA_SINK_HW_VOLUME_CTRL |
(u-mixer_path-has_dB ? PA_SINK_DECIBEL_VOLUME : 0);
-u-sink-flags |= PA_SINK_HW_VOLUME_CTRL | (u-mixer_path-has_dB ?
PA_SINK_DECIBEL_VOLUME : 0);
pa_log_info(Using hardware volume control. Hardware dB scale %s.,
u-mixer_path-has_dB ? supported : not supported);
}
I think this could be written more neatly.. e.g. more like:
u-sink-flags |= PA_SINK_HW_VOLUME_CTRL;
if (u-mixer_path-has_dB) {
u-sink-flags |= PA_SINK_DECIBEL_VOLUME;
if (sync_volume) {
u-sink-flags |= PA_SINK_SYNC_VOLUME;
pa_log_info();
}
}
While it's more assignment operations, I think it's easier to read what
is being done.
That's all for this one :)
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] [PATCH 4/5] daemon-conf: Add sync volume parameters to daemon-conf
'Twas brillig, and o...@iki.fi at 13/10/10 17:40 did gyre and gimble: From: Jyri Sarha jyri.sa...@nokia.com Signed-off-by: Jyri Sarha jyri.sa...@nokia.com Reviewed-by: Tanu Kaskinen tanu.kaski...@digia.com Reviewd-by: Colin Guthrie cguth...@mandriva.org -- 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] [PATCH 3/5] udev-detect: Add sync_volume parameter
'Twas brillig, and o...@iki.fi at 13/10/10 17:40 did gyre and gimble: From: Jyri Sarha jyri.sa...@nokia.com Signed-off-by: Jyri Sarha jyri.sa...@nokia.com Reviewed-by: Tanu Kaskinen tanu.kaski...@digia.com Reviewed-by: Colin Guthrie cguth...@mandriva.org -- 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] [PATCH 5/5] man: sync_volume parameters to manual page
'Twas brillig, and o...@iki.fi at 13/10/10 17:40 did gyre and gimble: From: Jyri Sarha jyri.sa...@nokia.com Signed-off-by: Jyri Sarha jyri.sa...@nokia.com Reviewed-by: Tanu Kaskinen tanu.kaski...@digia.com Please find attached a revised version of this patch... not sure if this is the best way to apply it for your tree, but meh! :p Cheers again for this. 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/] From a07a96a2777b9aa0dbd3ade76d56d3e641f20a40 Mon Sep 17 00:00:00 2001 From: Jyri Sarha jyri.sa...@nokia.com Date: Wed, 13 Oct 2010 19:40:22 +0300 Subject: [PATCH] man: sync_volume parameters to manual page Some wording teaks by Colin Guthrie Signed-off-by: Jyri Sarha jyri.sa...@nokia.com Reviewed-by: Tanu Kaskinen tanu.kaski...@digia.com --- man/pulse-daemon.conf.5.xml.in | 26 ++ 1 files changed, 26 insertions(+), 0 deletions(-) diff --git a/man/pulse-daemon.conf.5.xml.in b/man/pulse-daemon.conf.5.xml.in index b5c9e92..f0a642b 100644 --- a/man/pulse-daemon.conf.5.xml.in +++ b/man/pulse-daemon.conf.5.xml.in @@ -437,6 +437,32 @@ USA. /section + section name=Default Sync Volume Settings + +pThe flat volume feature sets the sink HW volume according to the +highest volume input stream and reduces the volume any other streams +(with lower volumes) in SW. To make this concurrent and ensure SW and +HW volume work together without any glitches, their application needs to +be synchronized. The sink implementation needs to support this +feature in order to these parameters to take effect./p + +option + poptenable-sync-volume=/opt Enable sync volume for the sinks that + support it. This feature is enabled by default./p +/option +option + poptsync-volume-safety-margin-usec=/opt The unit of time by which + the HW volume increases are delayed and HW volume decreases are advanced. + Defaults to 8000 usec./p +/option +option + poptsync-volume-extra-delay-usec=/opt The unit of time all HW + volume changes are delayed. Negative values are also allowed. + Defaults to 0./p +/option + + /section + section name=Authors pThe PulseAudio Developers lt;@PACKAGE_BUGREPORT@gt;; PulseAudio is available from url href=@PACKAGE_URL@//p /section -- 1.7.3.1 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC - MP3 passthrough over A2DP 1/2] mp3 passthrough: core changes
There's no real way you can extract timing information just by looking at the data. You either need to parse the frames (what I did for the BT work) or let the hardware report the number of samples it decoded and rendered. In both cases, you could find out what the average bit rate is and have an approximate idea of the relationship between the numbers of bytes passed to pulseaudio and the duration. It would be a bad idea though to rely on this approximated bitrate to infer timing. The client should get the audio time as reported by this sample count, not through inversion of an approximation that will only be correct for constant bit rates. Instead of basing all time ports on GET_LATENCY messages we should really have a new GET_TIME message. Why can't the encoded data for MP3 be handled the same way as DTS/AC3 over spdif/hdmi? They are preformatted with a iec958 header and padded with zeroes to the correct sample length given samplerate and channel count. To padding and adding of this header is up to the application. Now if a2dp supports mp3 as a raw format can't the a2dp code in bluez or whatever is communicating with the a2dp device strip the header. This way timing through pulse remains simple.. That's exactly my plan. I experimented with raw frames and it turned out to require too many changes. So yes the Mp3 stream would be reformatted as an IEC61937 format, and the pulseaudio sink would indeed strip the additional header and padding. The issue is that you can have different IEC61937 formats, and I would like to have additional information passed rather than the existing 'passthrough' flag. This is mainly need to make sure you link a sink_input with a sink that supports the relevant format. -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH] Explicitly link against pulse libraries
From: Luke Yelavich luke.yelav...@canonical.com When building pulseaudio master using gcc 4.5.2 and binutils 2.20.51 plus latest snapshot from 2010-10-14, ld complained about missing symbols. This patch explicitly links more pulseaudio libraries to satisfy the linker. Signed-off-by: Luke Yelavich luke.yelav...@canonical.com --- src/Makefile.am | 36 ++-- 1 files changed, 18 insertions(+), 18 deletions(-) diff --git a/src/Makefile.am b/src/Makefile.am index 4061b3c..df268ee 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -356,7 +356,7 @@ endif mainloop_test_SOURCES = tests/mainloop-test.c mainloop_test_CFLAGS = $(AM_CFLAGS) -mainloop_test_LDADD = $(AM_LDADD) libpulse.la +mainloop_test_LDADD = $(AM_LDADD) libpulse.la libpulsecomm...@pa_majorminormicro@.la mainloop_test_LDFLAGS = $(AM_LDFLAGS) $(BINLDFLAGS) thread_mainloop_test_SOURCES = tests/thread-mainloop-test.c @@ -366,7 +366,7 @@ thread_mainloop_test_LDFLAGS = $(AM_LDFLAGS) $(BINLDFLAGS) utf8_test_SOURCES = tests/utf8-test.c utf8_test_CFLAGS = $(AM_CFLAGS) -utf8_test_LDADD = $(AM_LDADD) libpulseco...@pa_majorminormicro@.la libpulsecomm...@pa_majorminormicro@.la +utf8_test_LDADD = $(AM_LDADD) libpulseco...@pa_majorminormicro@.la libpulsecomm...@pa_majorminormicro@.la libpulse.la utf8_test_LDFLAGS = $(AM_LDFLAGS) $(BINLDFLAGS) get_binary_name_test_SOURCES = tests/get-binary-name-test.c @@ -386,22 +386,22 @@ hook_list_test_LDFLAGS = $(AM_LDFLAGS) $(BINLDFLAGS) memblock_test_SOURCES = tests/memblock-test.c memblock_test_CFLAGS = $(AM_CFLAGS) -memblock_test_LDADD = $(AM_LDADD) libpulseco...@pa_majorminormicro@.la libpulsecomm...@pa_majorminormicro@.la +memblock_test_LDADD = $(AM_LDADD) libpulseco...@pa_majorminormicro@.la libpulsecomm...@pa_majorminormicro@.la libpulse.la memblock_test_LDFLAGS = $(AM_LDFLAGS) $(BINLDFLAGS) thread_test_SOURCES = tests/thread-test.c thread_test_CFLAGS = $(AM_CFLAGS) -thread_test_LDADD = $(AM_LDADD) libpulseco...@pa_majorminormicro@.la libpulsecomm...@pa_majorminormicro@.la +thread_test_LDADD = $(AM_LDADD) libpulseco...@pa_majorminormicro@.la libpulsecomm...@pa_majorminormicro@.la libpulse.la thread_test_LDFLAGS = $(AM_LDFLAGS) $(BINLDFLAGS) once_test_SOURCES = tests/once-test.c once_test_CFLAGS = $(AM_CFLAGS) -once_test_LDADD = $(AM_LDADD) libpulseco...@pa_majorminormicro@.la libpulsecomm...@pa_majorminormicro@.la +once_test_LDADD = $(AM_LDADD) libpulseco...@pa_majorminormicro@.la libpulsecomm...@pa_majorminormicro@.la libpulse.la once_test_LDFLAGS = $(AM_LDFLAGS) $(BINLDFLAGS) flist_test_SOURCES = tests/flist-test.c flist_test_CFLAGS = $(AM_CFLAGS) -flist_test_LDADD = $(AM_LDADD) libpulseco...@pa_majorminormicro@.la libpulsecomm...@pa_majorminormicro@.la +flist_test_LDADD = $(AM_LDADD) libpulseco...@pa_majorminormicro@.la libpulsecomm...@pa_majorminormicro@.la libpulse.la flist_test_LDFLAGS = $(AM_LDFLAGS) $(BINLDFLAGS) asyncq_test_SOURCES = tests/asyncq-test.c @@ -441,7 +441,7 @@ parec_simple_LDFLAGS = $(AM_LDFLAGS) $(BINLDFLAGS) strlist_test_SOURCES = tests/strlist-test.c strlist_test_CFLAGS = $(AM_CFLAGS) -strlist_test_LDADD = $(AM_LDADD) $(WINSOCK_LIBS) libpulseco...@pa_majorminormicro@.la libpulsecomm...@pa_majorminormicro@.la +strlist_test_LDADD = $(AM_LDADD) $(WINSOCK_LIBS) libpulseco...@pa_majorminormicro@.la libpulsecomm...@pa_majorminormicro@.la libpulse.la strlist_test_LDFLAGS = $(AM_LDFLAGS) $(BINLDFLAGS) close_test_SOURCES = tests/close-test.c @@ -451,7 +451,7 @@ close_test_LDFLAGS = $(AM_LDFLAGS) $(BINLDFLAGS) voltest_SOURCES = tests/voltest.c voltest_CFLAGS = $(AM_CFLAGS) -voltest_LDADD = $(AM_LDADD) libpulse.la +voltest_LDADD = $(AM_LDADD) libpulse.la libpulsecomm...@pa_majorminormicro@.la voltest_LDFLAGS = $(AM_LDFLAGS) $(BINLDFLAGS) vector_test_SOURCES = tests/vector-test.c @@ -466,12 +466,12 @@ channelmap_test_LDFLAGS = $(AM_LDFLAGS) $(BINLDFLAGS) cpulimit_test_SOURCES = tests/cpulimit-test.c daemon/cpulimit.c daemon/cpulimit.h cpulimit_test_CFLAGS = $(AM_CFLAGS) -cpulimit_test_LDADD = $(AM_LDADD) libpulseco...@pa_majorminormicro@.la libpulsecomm...@pa_majorminormicro@.la +cpulimit_test_LDADD = $(AM_LDADD) libpulseco...@pa_majorminormicro@.la libpulsecomm...@pa_majorminormicro@.la libpulse.la cpulimit_test_LDFLAGS = $(AM_LDFLAGS) $(BINLDFLAGS) cpulimit_test2_SOURCES = tests/cpulimit-test.c daemon/cpulimit.c daemon/cpulimit.h cpulimit_test2_CFLAGS = $(AM_CFLAGS) -DTEST2 -cpulimit_test2_LDADD = $(AM_LDADD) libpulseco...@pa_majorminormicro@.la libpulsecomm...@pa_majorminormicro@.la +cpulimit_test2_LDADD = $(AM_LDADD) libpulseco...@pa_majorminormicro@.la libpulsecomm...@pa_majorminormicro@.la libpulse.la cpulimit_test2_LDFLAGS = $(AM_LDFLAGS) $(BINLDFLAGS) mainloop_test_glib_SOURCES = $(mainloop_test_SOURCES) @@ -500,17 +500,17 @@ sig2str_test_CFLAGS = $(AM_CFLAGS) sig2str_test_LDFLAGS = $(AM_LDFLAGS) $(BINLDFLAGS) resampler_test_SOURCES = tests/resampler-test.c
[pulseaudio-discuss] [PATCH] Explicitly link against pulse libraries
From: Luke Yelavich luke.yelav...@canonical.com When building pulseaudio stable-queue using gcc 4.5.2 and binutils 2.20.51 plus latest snapshot from 2010-10-14, ld complained about missing symbols. This patch explicitly links more pulseaudio libraries to satisfy the linker. Signed-off-by: Luke Yelavich luke.yelav...@canonical.com --- src/Makefile.am | 34 +- 1 files changed, 17 insertions(+), 17 deletions(-) diff --git a/src/Makefile.am b/src/Makefile.am index 8dd5793..b130353 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -370,7 +370,7 @@ endif mainloop_test_SOURCES = tests/mainloop-test.c mainloop_test_CFLAGS = $(AM_CFLAGS) -mainloop_test_LDADD = $(AM_LDADD) libpulse.la +mainloop_test_LDADD = $(AM_LDADD) libpulse.la libpulsecomm...@pa_majorminormicro@.la mainloop_test_LDFLAGS = $(AM_LDFLAGS) $(BINLDFLAGS) thread_mainloop_test_SOURCES = tests/thread-mainloop-test.c @@ -380,7 +380,7 @@ thread_mainloop_test_LDFLAGS = $(AM_LDFLAGS) $(BINLDFLAGS) utf8_test_SOURCES = tests/utf8-test.c utf8_test_CFLAGS = $(AM_CFLAGS) -utf8_test_LDADD = $(AM_LDADD) libpulseco...@pa_majorminormicro@.la libpulsecomm...@pa_majorminormicro@.la +utf8_test_LDADD = $(AM_LDADD) libpulseco...@pa_majorminormicro@.la libpulsecomm...@pa_majorminormicro@.la libpulse.la utf8_test_LDFLAGS = $(AM_LDFLAGS) $(BINLDFLAGS) get_binary_name_test_SOURCES = tests/get-binary-name-test.c @@ -400,17 +400,17 @@ hook_list_test_LDFLAGS = $(AM_LDFLAGS) $(BINLDFLAGS) memblock_test_SOURCES = tests/memblock-test.c memblock_test_CFLAGS = $(AM_CFLAGS) -memblock_test_LDADD = $(AM_LDADD) libpulseco...@pa_majorminormicro@.la libpulsecomm...@pa_majorminormicro@.la +memblock_test_LDADD = $(AM_LDADD) libpulseco...@pa_majorminormicro@.la libpulsecomm...@pa_majorminormicro@.la libpulse.la memblock_test_LDFLAGS = $(AM_LDFLAGS) $(BINLDFLAGS) thread_test_SOURCES = tests/thread-test.c thread_test_CFLAGS = $(AM_CFLAGS) -thread_test_LDADD = $(AM_LDADD) libpulseco...@pa_majorminormicro@.la libpulsecomm...@pa_majorminormicro@.la +thread_test_LDADD = $(AM_LDADD) libpulseco...@pa_majorminormicro@.la libpulsecomm...@pa_majorminormicro@.la libpulse.la thread_test_LDFLAGS = $(AM_LDFLAGS) $(BINLDFLAGS) flist_test_SOURCES = tests/flist-test.c flist_test_CFLAGS = $(AM_CFLAGS) -flist_test_LDADD = $(AM_LDADD) libpulseco...@pa_majorminormicro@.la libpulsecomm...@pa_majorminormicro@.la +flist_test_LDADD = $(AM_LDADD) libpulseco...@pa_majorminormicro@.la libpulsecomm...@pa_majorminormicro@.la libpulse.la flist_test_LDFLAGS = $(AM_LDFLAGS) $(BINLDFLAGS) asyncq_test_SOURCES = tests/asyncq-test.c @@ -450,7 +450,7 @@ parec_simple_LDFLAGS = $(AM_LDFLAGS) $(BINLDFLAGS) strlist_test_SOURCES = tests/strlist-test.c strlist_test_CFLAGS = $(AM_CFLAGS) -strlist_test_LDADD = $(AM_LDADD) $(WINSOCK_LIBS) libpulseco...@pa_majorminormicro@.la libpulsecomm...@pa_majorminormicro@.la +strlist_test_LDADD = $(AM_LDADD) $(WINSOCK_LIBS) libpulseco...@pa_majorminormicro@.la libpulsecomm...@pa_majorminormicro@.la libpulse.la strlist_test_LDFLAGS = $(AM_LDFLAGS) $(BINLDFLAGS) close_test_SOURCES = tests/close-test.c @@ -460,7 +460,7 @@ close_test_LDFLAGS = $(AM_LDFLAGS) $(BINLDFLAGS) voltest_SOURCES = tests/voltest.c voltest_CFLAGS = $(AM_CFLAGS) -voltest_LDADD = $(AM_LDADD) libpulse.la +voltest_LDADD = $(AM_LDADD) libpulse.la libpulsecomm...@pa_majorminormicro@.la voltest_LDFLAGS = $(AM_LDFLAGS) $(BINLDFLAGS) vector_test_SOURCES = tests/vector-test.c @@ -475,12 +475,12 @@ channelmap_test_LDFLAGS = $(AM_LDFLAGS) $(BINLDFLAGS) cpulimit_test_SOURCES = tests/cpulimit-test.c daemon/cpulimit.c daemon/cpulimit.h cpulimit_test_CFLAGS = $(AM_CFLAGS) -cpulimit_test_LDADD = $(AM_LDADD) libpulseco...@pa_majorminormicro@.la libpulsecomm...@pa_majorminormicro@.la +cpulimit_test_LDADD = $(AM_LDADD) libpulseco...@pa_majorminormicro@.la libpulsecomm...@pa_majorminormicro@.la libpulse.la cpulimit_test_LDFLAGS = $(AM_LDFLAGS) $(BINLDFLAGS) cpulimit_test2_SOURCES = tests/cpulimit-test.c daemon/cpulimit.c daemon/cpulimit.h cpulimit_test2_CFLAGS = $(AM_CFLAGS) -DTEST2 -cpulimit_test2_LDADD = $(AM_LDADD) libpulseco...@pa_majorminormicro@.la libpulsecomm...@pa_majorminormicro@.la +cpulimit_test2_LDADD = $(AM_LDADD) libpulseco...@pa_majorminormicro@.la libpulsecomm...@pa_majorminormicro@.la libpulse.la cpulimit_test2_LDFLAGS = $(AM_LDFLAGS) $(BINLDFLAGS) mainloop_test_glib_SOURCES = $(mainloop_test_SOURCES) @@ -509,17 +509,17 @@ sig2str_test_CFLAGS = $(AM_CFLAGS) sig2str_test_LDFLAGS = $(AM_LDFLAGS) $(BINLDFLAGS) resampler_test_SOURCES = tests/resampler-test.c -resampler_test_LDADD = $(AM_LDADD) libpulseco...@pa_majorminormicro@.la libpulsecomm...@pa_majorminormicro@.la +resampler_test_LDADD = $(AM_LDADD) libpulseco...@pa_majorminormicro@.la libpulsecomm...@pa_majorminormicro@.la libpulse.la resampler_test_CFLAGS = $(AM_CFLAGS) resampler_test_LDFLAGS = $(AM_LDFLAGS) $(BINLDFLAGS) mix_test_SOURCES =
