Re: [pulseaudio-discuss] module-echo-cancel
On Fri, 2011-05-27 at 09:13 -0700, Baek Chang wrote: [...] > Well there was a lot of feedback, I was essentially doing an arecord > and piping that to play, so a loopback test from mic to speakers. > I am on Qualcomm soc. First try to get rid of the feedback and switch to 8 or 16 kHz. If you see a lot of messages about dropped samples, chances are that the timing information from your ALSA driver is inaccurate. [...] > No, the voip stack should be at 8 or 16kHz like you said, I was just > trying this without voip and it was set up at 44.1kHz. I can try it > at 8kHz mono and see if this improves the cpu usage and echo. It definitely will improve CPU usage. Hopefully echo levels as well. I think it might be good to spit out a warning for rates >16 kHz, or even make 16 kHz + mono the default. -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] How to check audio sample data to a bluetooth sink?
On Fri, 2011-05-27 at 17:56 +0800, Lin, Mengdong wrote: > Could anybody tell me how dump the data to a Bluetooth sink from a > VOIP sink input stream? Which function shall I hack? > > > > I try to run GTalk with Bluetooth headset. I set the card profile to > HSP. And the input stream/output stream are connected to the Bluetooth > sink/source. > > But I cannot hear the voice from the other side. Increasing the volume > of sink or sink input does not work. In fact, I tried a very large > number but the VOIP stream keeps quite in my BT headset. > > If I launch a music player at the same time and also move the stream > to the Bluetooth sink (HSP), I can hear the song. It means the BT sink > is working. > > If I disconnect Bluetooth handset and switch to speaker, I can here > weak voice from GTalk. Does the data become invalid when it’s > connected to BT sink? > > > > So I want to check the input data from GTalk to the Bluetooth sink, to > see whether the data is bad or just too weak for the BT headset. You could just run pavucontrol which gives you a vu meter of the various recording and playback levels. You can also connect to the monitor source of the sink to capture the actual data. -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PACKAGERS] New dep
On Fri, 2011-05-27 at 00:22 +0530, Arun Raghavan wrote: [...] > you speak of is a recent development. I'll mail the developers and ask > them what's happening. Should be up in a day or so. -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PACKAGERS] New dep
On Thu, 2011-05-26 at 16:23 +0200, Maarten Bosmans wrote: > 2011/5/16 Colin Guthrie : > > Hi, > > > > I've just pushed Arun's (mostly, Pierre-Louis also had a hand!) > > passthrough work to master. > > > > This carries with it a new dependency: json-c > > What is the upstream location of that software? Googling for json > implementations gives a lot of small libraries, it is not clear which > one is needed as the pulse dep. Yes, it's unfortunate that it's a buzz word and the library name doesn't generate unique search results. > I guess it could be the one at http://oss.metaparadigm.com/json-c/, > but that website is out of order for some time now. The .tar file is > only locatable through the packaging systems of various Linux > distros/BSDs. The website worked fine as of a month ago. I don't know why it's down now. The library serves the purpose we need well (light weight, doesn't invent its own type system, allows you to parse out values individually instead of mandating key-value pairs), and is available on every major distribution ... > Needless to say, such an unclear status of a dependency is not really > helpfull in packaging PulseAudio. ... so the dependency was not picked arbitrarily and the unclear status you speak of is a recent development. I'll mail the developers and ask them what's happening. -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] module-echo-cancel
On Thu, 2011-05-26 at 10:07 -0700, Baek Chang wrote: > I'm trying to use the echo cancellation module on my embedded platform > but it seems to be taking all the cpu usage and renders audio useless. > > > I'm continually seeing these messages: > warning: The echo canceller started acting funny and got slapped > (reset). It swears it will behave now. This particular message is surprising. Was there a lot of feedback when you saw this? It's also possible that your clock is drifting a lot and is thus causing the echo canceller to give up. What hardware are you trying this on? > D: module-echo-cancel.c: diff -269 (43555 - 88163 + 44155) 0 0 9600 > 184 > E: module-echo-cancel.c: Playback after capture (-269), drop sink 84 > warning: The echo canceller started acting funny and got slapped > (reset). It swears it will behave now. > warning: The echo canceller started acting funny and got slapped > (reset). It swears it will behave now. > D: module-echo-cancel.c: diff 475 (42663 - 87687 + 45315) 0 0 9600 184 > warning: The echo canceller started acting funny and got slapped > (reset). It swears it will behave now. > D: module-echo-cancel.c: diff 168 (39254 - 87687 + 48410) 0 0 9600 191 > D: module-echo-cancel.c: diff -411 (38089 - 87687 + 49002) 0 0 9600 > 185 > E: module-echo-cancel.c: Playback after capture (-411), drop sink 112 > warning: The echo canceller started acting funny and got slapped > (reset). It swears it will behave now. > warning: The echo canceller started acting funny and got slapped > (reset). It swears it will behave now. > D: module-echo-cancel.c: diff 1491 (41407 - 87052 + 46961) 0 0 9600 > 175 > E: module-echo-cancel.c: playback too far ahead (1491), drop source > 260 > warning: The echo canceller started acting funny and got slapped > (reset). It swears it will behave now. > warning: The echo canceller started acting funny and got slapped > (reset). It swears it will behave now. > D: module-echo-cancel.c: diff -1166 (44921 - 88526 + 42252) 0 0 9600 > 187 > E: module-echo-cancel.c: Playback after capture (-1166), drop sink 244 > > > cpu is at 90-100% at the highest cpu scaling. > > > I was loading the module like so in my .pa conf file: > > > load-module module-echo-cancel source_name=echosource > source_master=pcm_input sink_name=echosink sink_master=pcm_output > rate=44100 channels=2 Do you really need to work with 44.1 kHz stereo streams? Your voip stack is probably working with 8 or 16 kHz audio and running in single channel mode would probably not make a difference either. It will, however, make a huge difference with respect to your CPU consumption. I pushed some more preprocessing code to module-echo-cancel yesterday, but there's a bit of a bug which I should be pushing a fix for by tomorrow. Once that's done, you can try it out by passing agc=1 / denoise=1 / echo_suppress=1. We're still looking at various potential improvements to get AEC working better, and I'll try to post a status in the coming weeks as things start to improve. You may also want to play with aec_method=adrian, which is an alternate canceller. It seems to learn faster than speex, but leaves a larger echo residue compared to once speex has had sufficient time to learn. Cheers, Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Source Output Volumes
On Fri, 2011-05-20 at 09:50 +0100, Colin Guthrie wrote: > 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. This is really nice to have - thanks! > 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've not been able to test things extensively yet, but some comments: I've pushed a couple of patches on top of your tree, one trivial, one adds a set-source-output-volume to pactl at http://cgit.collabora.com/git/user/arun/pulseaudio.git/log/?h=master-source-volume 29cd2d78 capture: Add the passthrough format negitiation to capture streams. * There's typo in the commit message * Just in case I forget, the fix we were discussion for ownwership of the formats idxset in pa_sink_input_new_data_set_formats() needs to be added to pa_source_output_new_data_set_formats() as well * This is tangential to your work, but maybe we should just break compatibility with versions older than 0.9.20? (protocol version < 17) It'll make the code easier to read. o94d2b5 capture: Implement per-stream volume control for capture streams. * I don't see the source output changes actually show up in the samples (I'm opening two gnome-volume-recorder instances, doing a pactl set-source-output-volume on one, but the levels are identical before and after). Is there a missing pa_volume_memchunk in pa_source_output_push() or am I just doing something stupid? * module-echo-cancel.c - there's an s->volume inside #if 0 * [Not actually from your changes] pa_source_process_msg() - does it matter that the order of detach and set state within thread inverted compared to sink-input? * Again, this is for later, but we should eventually stop suspending monitors and change the source format dynamically. Will do some more extensive testing and port pulsesrc when I get some time as well. Cheers, Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] How to find the latest created bluetooth sink/source via event hook?
On Thu, 2011-05-19 at 10:09 +0800, Lin, Mengdong wrote: > Great thanks for your advice, Col! > > > Please note that there already exists a module called > > module-switch-on-connect which does this task, but for all new sinks, > > not just BT sinks. ... > > I found "module-switch-on-connect.c" is not in 0.9.22 tar ball but in git. > When will this module be released? > My work is still based on 0.9.22 and need upgrade to use this module. > > > Just so you know, I will am intending on shaking up the routing system > > in PA after v1 is released which will hopefully make this kind of thing > > easier to implement and manage. ... but essentially the routing will be > > based on priority lists of > > devices rather than just setting a single device to use. > > It sounds great! Could you share more information on this new design, maybe > in a new thread? http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/ Cheers, Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] build error
On Wed, 2011-05-18 at 12:00 +0530, Himanshu Chug wrote:
> Hello All,
>
> This is first mail to the list, Hello to evreyone in the list,
Hello. :)
> I am new to pulseaudio and I am trying to build the pulseaudio using
> make and get the following build errors:
>
> {standard input}: Assembler messages:
> {standard input}:64: Error: selected processor does not support ARM
> mode `ssat r0,#16,r0'
> {standard input}:79: Error: selected processor does not support ARM
> [...]
> can someone help me to resolve these errors. Thanks in advance
This problem has been fixed in the master and in stable-queue branches,
so it'll be resolved in the next release (which should hopefully happen
before too long). Patch is at here if you want to apply it yourself:
http://git.0pointer.de/?p=pulseaudio.git;a=commitdiff;h=12b900858ae82d435c100d6eb94cb7bb22fe5e29
Cheers,
Arun
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] volume ramping
On Mon, 2011-05-16 at 18:21 -0700, Baek Chang wrote: > Hi, > > > There used to be some test/sample code that did volume ramping on > pulseaudio git source. Recently it has been taken out. Any idea as > to why, the revert commits did not mention a reason. > I've been testing it out and it seems stable, I did have to change > some of the logic and code to get it working without glitches. You can see discussion about this in the last IRC meeting logs (1 d) at: http://colin.guthr.ie/meetings/pulseaudio-meeting/2011/pulseaudio-meeting.2011-02-24-17.08.html -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] review+pull-request: Passthrough support
On Tue, 2011-05-03 at 09:25 +0100, Colin Guthrie wrote: > 'Twas brillig, and Arun Raghavan at 02/05/11 07:49 did gyre and gimble: > >> > In e193c2bf55326a48e2297bcacadc9d1848a40d7d and > >> > 948d0f19bef353208ffb5b1b8c520b6b489b94a6 > >> > > >> > Can you make sure that pactl and pacmd stay as in-sync as possible? > > I held off because I thought that pacmd was going to be dropped before > > too long. Is this not the case? Sink port information seems to have not > > been added, I'll sync that as well if required. > > Hmm, not sure. Ideally I'd prefer to just have one tool and only add to > pacmd the things that cannot easily be done via the protocol, but I'm > not sure of the overall strategy. > > I'll add this to the discussion points for Saturday's chat. Was this discussed? Any news? > >> > In bb7cc499f1815de1c90b0ef1850152224df96ff9 > >> > > >> > I don't see why this asserts in the current form nor what has actually > >> > changed. > > It should not assert since we want to gracefully fail (that is the > > original code should not have been an assert). > > I still don't see any asserts in the original code. The only difference > I can see is that a pa_log_debug() is not printed... (the log message > says the word "Assertion" but it doesn't actually assert AFAICT...) > > This might be intended (i.e. don't print the log message), but if that's > the case the commit message is still wrong to mention asserts... Ah, I see what you mean. Commit message amended. > >> > General Question: > >> > > >> > Has this broken tunnels? (we manage to do this quite often with stream > >> > protocol changes... > > Indeed, it does. I've put fixing this on my TODO list. Will try to get > > to it soon. > > Cool, thanks :) Done and pushed to my tree. :) Cheers, Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH] echo-cancel: Remove unnecessary noalign attribute
This was just introduced for debugging and should not have been in the
final commit. Won't make a difference at the moment since this function
is used as a pointer, but removing this in case we change this in the
future.
---
src/modules/echo-cancel/adrian-aec.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/src/modules/echo-cancel/adrian-aec.c
b/src/modules/echo-cancel/adrian-aec.c
index dfe8ada..e969e8c 100644
--- a/src/modules/echo-cancel/adrian-aec.c
+++ b/src/modules/echo-cancel/adrian-aec.c
@@ -40,7 +40,6 @@ static REAL dotp(REAL a[], REAL b[])
return sum0 + sum1;
}
-static REAL dotp_sse(REAL a[], REAL b[]) __attribute__((noinline));
static REAL dotp_sse(REAL a[], REAL b[])
{
#ifdef __SSE__
--
1.7.5.rc3
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH] echo-cancel: Handle alignment requirement manually
PA_ALIGNED can't always guarantee that the alignment we want (the GCC
man page suggests that the linker might not be able to meet the
alignment requirements we desire). Instead, we now allocate some extra
memory and guaratee that the alignment we require is met.
---
src/modules/echo-cancel/adrian-aec.c | 12 +---
src/modules/echo-cancel/adrian-aec.h |3 ++-
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/src/modules/echo-cancel/adrian-aec.c
b/src/modules/echo-cancel/adrian-aec.c
index 04b31e9..dfe8ada 100644
--- a/src/modules/echo-cancel/adrian-aec.c
+++ b/src/modules/echo-cancel/adrian-aec.c
@@ -12,6 +12,7 @@
#include
#include
+#include
#include
@@ -70,7 +71,7 @@ AEC* AEC_init(int RATE, int have_vector)
a->hangover = 0;
memset(a->x, 0, sizeof(a->x));
memset(a->xf, 0, sizeof(a->xf));
- memset(a->w, 0, sizeof(a->w));
+ memset(a->w_arr, 0, sizeof(a->w_arr));
a->j = NLMS_EXT;
a->delta = 0.0f;
AEC_setambient(a, NoiseFloor);
@@ -89,10 +90,15 @@ AEC* AEC_init(int RATE, int have_vector)
a->dumpcnt = 0;
memset(a->ws, 0, sizeof(a->ws));
- if (have_vector)
+ if (have_vector) {
+ /* Get a 16-byte aligned location */
+ a->w = (REAL *) (((uintptr_t) a->w_arr) + (((uintptr_t) a->w_arr) % 16));
a->dotp = dotp_sse;
- else
+ } else {
+ /* We don't care about alignment, just use the array as-is */
+ a->w = a->w_arr;
a->dotp = dotp;
+ }
return a;
}
diff --git a/src/modules/echo-cancel/adrian-aec.h
b/src/modules/echo-cancel/adrian-aec.h
index 9c722b9..efb9e27 100644
--- a/src/modules/echo-cancel/adrian-aec.h
+++ b/src/modules/echo-cancel/adrian-aec.h
@@ -306,7 +306,8 @@ struct AEC {
// NLMS-pw
REAL x[NLMS_LEN + NLMS_EXT]; // tap delayed loudspeaker signal
REAL xf[NLMS_LEN + NLMS_EXT]; // pre-whitening tap delayed signal
- PA_DECLARE_ALIGNED(16, REAL, w[NLMS_LEN]); // tap weights
+ REAL w_arr[NLMS_LEN+16]; // tap weights
+ REAL *w; // this will be a 16-byte aligned pointer into
w_arr
int j;// optimize: less memory copies
double dotp_xf_xf;// double to avoid loss of precision
float delta; // noise floor to stabilize NLMS
--
1.7.5.rc1
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] several seconds delay while playing video with timer-based audio scheduling enabled
On Thu, 2011-05-05 at 23:37 -0400, xing wang wrote: > 2011/5/5 xing wang : > > 2011/5/5 Colin Guthrie : > >> 'Twas brillig, and xing wang at 05/05/11 10:24 did gyre and gimble: > >>> Hi community, > >>> > >>> I met a weird issue when playing video on Meego Platform. > >>> if turn on timer-based audio scheduling, there's nearly seconds voice > >>> delay during playing video. > >>> The abnormal phenomenon disappeared after turn it off. > >>> > >>> I use 2.6.37 kernel and 0.9.22 pulseaudio version. As suggestions > >>> (http://0pointer.de/blog/projects/pulse-glitch-free.html) > >>> the pulseaudio's glitch-free works on newest Alsa/Kernel/Pulseaudio, > >>> newest everything. > >>> > >>> After some google search, there's no obvious finding about similar > >>> issues. Meanwhile i guess the official release of glitch-free > >>> must be verified about "tsched" feature, so it's not a bug but a usage > >>> mistake,such as some config file wrong for my platform. > >>> > >>> So if anyone had meet same issue or could you provide some > >>> suggestions, that would be appreciated much. > >> > >> What video player is being used? It is perhaps making some really dumb > >> assumptions about things and thus breaking (and using too much power too!) > > > > It's Meego default player "meego-qml-launcher". > > Maybe wrong here. Qml-launcher is only one app launcher, the exact app name is > "meego-app-video", it's one QML based application. What hardware are you trying this on, btw? -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] ORC buildsystem problems
On Mon, 2011-05-02 at 11:52 +0200, Maarten Bosmans wrote: > Recently, I encountered some problems when enabling orc in some less > usual situations. > > When compiling with --enable-orc from a tarball generated from a > --disable-orc configured tree, the following error occurs. > make[2]: *** No rule to make target `pulsecore/svolume-orc-gen.c', > needed by `all'. Stop > I haven't really looked at a solution. Perhaps the nodist_ prefix for > some files inside if HAVE_ORC in src/Makefile.am should be dropped? > May be Colin needs to do his make distchecks with this situation, in > order to catch it earlier. There should not be a dist'ed tarball without those generated files. Whether they are used or not is a configure-time option, then. > Secondly, there is a problem when cross-compiling. The pkg-config > check for ORC is used to find the usual include files and linking > flags, but also to find the location of orcc. This is a problem, > because when configure is run with the correct configuration, such > that pkg-config finds the host package, it also finds the host orcc > (in the case of my mingw32 test, it finds orcc.exe), which is of > course useless in the build environment. Why is it useless in your environment? The files generated by orcc are architecture-neutral. Cheers, Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] review+pull-request: Passthrough support
On Sun, 2011-04-24 at 20:52 +0100, Colin Guthrie wrote: > 'Twas brillig, and Arun Raghavan at 13/04/11 13:53 did gyre and gimble: > > Hey folks, > > My passthrough work is now at a point where I think it's good to pull to > > master. All the core code for clients to signal that they are providing > > a compressed format, and sinks to signal what formats they support is > > there. The API is essentially the same as discussed earlier on-list, > > with some small tweaks along the way as necessary. > > > > Still pending are proper detection/signalling of available formats on > > ALSA devices is to be done (Colin's looking at some of the plumbing for > > S/PDIF, and HDMI ELD/EDID-based lookups are something that we need as > > well), and better handling of monitors (we suspend them for now, which > > works), and volumes (Tanu's got some on-going work on this). > > > > NOTE: given the above about ALSA, topmost patch should probably not be > > pulled, but is handy to have for testing. > > > > In addition to the passthrough branch, there is a passthrough-bt branch > > which has changes to the bluetooth sink to support streaming MP3 to > > headsets that support it. This also needs some work before being ready > > to pull. > > > > The changes needed to actually use this in GStreamer are also done, but > > not upstream yet. I need to do some rebasing to make this stuff good to > > push out, so details on this in a following mail. > > > > Comments, feedback will be very much appreciated. :) > > > > are available in the git repository at: > > git://git.collabora.co.uk/git/user/arun/pulseaudio.git passthrough > > > Not tried the code (yet), but will do this week. I have reviewed all the > code yet! > > But I did review all the commits! Most of my comments are trivial tho' > (and some are already fixed it seems!) Thanks! :) > In 4a839b3767ae5571c69bd591b5a59d7307cba13e > > pa_format_info_to_sample_spec() and pa_format_info_to_sample_spec_fake() > some pa_assert's should pa_assert_se's. (Update: I think these are all > rectified in 38309769c5a630ee78ae73be6fb407624c1509fc) Yup, that bit's been rewritten without a lot of asserts. > In 7e8b65bc4f490628f20ab420a6c80bfa3a760bc6 > > Shouldn't pa_create_stream_callback() call > pa_tagstruct_get_format_info() up to n_format times and only bail if all > are invalid? The format we have at this point is the negotiated format, so there is only one. > Minor typo: "Send back the format me negotiated" s/me/we/ > > Minor typo: "We're working not working with the extended API" s/working > not/not/ > > pa_sink_input_new_data_set_formats(): Please drop the last "else" and > just put the "return TRUE" as the last statement. It's trivial but I > believe this looks neater to always have a return at the top level of > the function. Ack on all 3 counts. > In d885a39b9f1085e759ad69afcc939caffb1fbc5a > > Minor typo: "but this is can very well be incorrect" s/this is/this/ Also fixed. > In e193c2bf55326a48e2297bcacadc9d1848a40d7d and > 948d0f19bef353208ffb5b1b8c520b6b489b94a6 > > Can you make sure that pactl and pacmd stay as in-sync as possible? I held off because I thought that pacmd was going to be dropped before too long. Is this not the case? Sink port information seems to have not been added, I'll sync that as well if required. > In bb7cc499f1815de1c90b0ef1850152224df96ff9 > > I don't see why this asserts in the current form nor what has actually > changed. It should not assert since we want to gracefully fail (that is the original code should not have been an assert). > In 9d5e8867066e392fa40add0f0380374131dfc2de > > Minor: pa_streq has a space before the (. Check. > In d9e0f3bc0286249ced30a4728e4467f7a46f37af > > Already merged in 837e0a960630251ce30c124da5e65079b748d978 > > > > > Should we rebase before merge or is it wise to keep your tree as is for > ease of working with existing checkouts? I've done a rebase against current master and pushed to the same location. > General Question: > > Has this broken tunnels? (we manage to do this quite often with stream > protocol changes... Indeed, it does. I've put fixing this on my TODO list. Will try to get to it soon. Cheers, Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH] filter-apply: Mark modules as being autoloaded
(Based on Colin's review) We mark modules as being autoloaded so that
they can handle this as a special case if needed (which is required by
module-echo-cancel for now). This inverts how things were done and makes
using these modules manually less error-prone.
---
src/modules/echo-cancel/module-echo-cancel.c | 18 +-
src/modules/module-equalizer-sink.c | 13 -
src/modules/module-filter-apply.c|2 +-
src/modules/module-virtual-sink.c|3 +++
src/modules/module-virtual-source.c |3 +++
5 files changed, 28 insertions(+), 11 deletions(-)
diff --git a/src/modules/echo-cancel/module-echo-cancel.c
b/src/modules/echo-cancel/module-echo-cancel.c
index 746028b..3787962 100644
--- a/src/modules/echo-cancel/module-echo-cancel.c
+++ b/src/modules/echo-cancel/module-echo-cancel.c
@@ -78,7 +78,7 @@ PA_MODULE_USAGE(
"aec_method= "
"aec_args= "
"save_aec= "
- "manual_load= "
+ "autoloaded= "
));
/* NOTE: Make sure the enum and ec_table are maintained in the correct order */
@@ -107,7 +107,7 @@ static const pa_echo_canceller ec_table[] = {
#define DEFAULT_ADJUST_TIME_USEC (1*PA_USEC_PER_SEC)
#define DEFAULT_SAVE_AEC 0
-#define DEFAULT_MANUAL_LOAD FALSE
+#define DEFAULT_AUTOLOADED FALSE
#define MEMBLOCKQ_MAXLENGTH (16*1024*1024)
@@ -158,7 +158,7 @@ struct userdata {
pa_core *core;
pa_module *module;
-pa_bool_t manual_load;
+pa_bool_t autoloaded;
uint32_t save_aec;
pa_echo_canceller *ec;
@@ -213,7 +213,7 @@ static const char* const valid_modargs[] = {
"aec_method",
"aec_args",
"save_aec",
-"manual_load",
+"autoloaded",
NULL
};
@@ -1398,9 +1398,9 @@ int pa__init(pa_module*m) {
goto fail;
}
-u->manual_load = DEFAULT_MANUAL_LOAD;
-if (pa_modargs_get_value_boolean(ma, "manual_load", &u->manual_load) < 0) {
-pa_log("Failed to parse manual_load value");
+u->autoloaded = DEFAULT_AUTOLOADED;
+if (pa_modargs_get_value_boolean(ma, "autoloaded", &u->autoloaded) < 0) {
+pa_log("Failed to parse autoloaded value");
goto fail;
}
@@ -1423,7 +1423,7 @@ int pa__init(pa_module*m) {
pa_source_new_data_set_channel_map(&source_data, &source_map);
pa_proplist_sets(source_data.proplist, PA_PROP_DEVICE_MASTER_DEVICE,
source_master->name);
pa_proplist_sets(source_data.proplist, PA_PROP_DEVICE_CLASS, "filter");
-if (u->manual_load)
+if (!u->autoloaded)
pa_proplist_sets(source_data.proplist, PA_PROP_DEVICE_INTENDED_ROLES,
"phone");
pa_proplist_sets(source_data.proplist, "device.echo-cancel.name",
source_data.name);
@@ -1471,7 +1471,7 @@ int pa__init(pa_module*m) {
pa_sink_new_data_set_channel_map(&sink_data, &sink_map);
pa_proplist_sets(sink_data.proplist, PA_PROP_DEVICE_MASTER_DEVICE,
sink_master->name);
pa_proplist_sets(sink_data.proplist, PA_PROP_DEVICE_CLASS, "filter");
-if (u->manual_load)
+if (!u->autoloaded)
pa_proplist_sets(sink_data.proplist, PA_PROP_DEVICE_INTENDED_ROLES,
"phone");
pa_proplist_sets(sink_data.proplist, "device.echo-cancel.name",
sink_data.name);
diff --git a/src/modules/module-equalizer-sink.c
b/src/modules/module-equalizer-sink.c
index 0bbb23a..9a85fe5 100644
--- a/src/modules/module-equalizer-sink.c
+++ b/src/modules/module-equalizer-sink.c
@@ -83,14 +83,18 @@ PA_MODULE_USAGE(
"format= "
"rate= "
"channels= "
- "channel_map="));
+ "channel_map= "
+ "autoloaded= "
+ ));
#define MEMBLOCKQ_MAXLENGTH (16*1024*1024)
+#define DEFAULT_AUTOLOADED FALSE
struct userdata {
pa_module *module;
pa_sink *sink;
pa_sink_input *sink_input;
+pa_bool_t autoloaded;
size_t channels;
size_t fft_size;//length (res) of fft
@@ -138,6 +142,7 @@ static const char* const valid_modargs[] = {
"rate",
"channels",
"channel_map",
+"autoloaded",
NULL
};
@@ -1170,6 +1175,12 @@ int pa__init(pa_module*m) {
goto fail;
}
+u->autoloaded = DEFAULT_AUTOLOADED;
+if (pa_modargs_get_value_boolean(ma, "autoloaded", &u->autoloaded) < 0) {
+pa_log("Failed to parse autoloaded value");
+goto fail;
+}
+
u->sink = pa_sink_new(m->core, &sink_data,
PA_SINK_HW_MUTE_CTRL|PA_SINK_HW_VOLUME_CTRL|PA_SINK_DECIBEL_VOLUME|
(master->flags &
(PA_SINK_LATENCY|PA_SINK_DYNAMIC_LATENCY)));
diff --git a/src/modules/module-filter-apply.c
b/src/modules/module-filter-apply.c
index 79558f2..e9c9f65 100644
--- a/src/modules/module-filter-apply.c
+++ b/src/modules/module-filter-apply.c
@@ -314,7 +314,7 @@ static pa_hook_result_t process(struct userdata *u,
pa_object *o, pa_bool_t is_s
char *args;
pa_module *m;
-args = pa_sprintf_malloc("%s_master=%s", is_sink_in
Re: [pulseaudio-discuss] unsubscribe me please.
Hi, You need to unsubscribe yourself. This link should help: https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] glib functions on PA
On Thu, 2011-04-21 at 10:13 +0530, Arun Raghavan wrote: > On Wed, 2011-04-20 at 23:26 -0500, Margarita Olaya wrote: > > Hi, > > > > The initial implementation of jack detection is using threads and > > simple file operations like open, close and read currently I'm looking > > into using pa_threads and glib functions. First step It is simple > > enough e.g change threads by pa_threads and for file operations I have > > > > u->fd = g_open(u->device_id, O_RDONLY) > > ioch = g_io_channel_unix_new(u->fd); > > > > then use g_io_channel_read_chars() instead of read. > > > > I'm wonder if it is the beast approach or I'm missing any PA function > > that fits better for this purpose. > > I'm not aware of any PA code that uses glib for this. module-pipe-sink > seems to do most of the things you need so that might serve as a good > starting point. Actually, module-pipe-source is even closer to what you want to do. :) -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] glib functions on PA
On Wed, 2011-04-20 at 23:26 -0500, Margarita Olaya wrote: > Hi, > > The initial implementation of jack detection is using threads and > simple file operations like open, close and read currently I'm looking > into using pa_threads and glib functions. First step It is simple > enough e.g change threads by pa_threads and for file operations I have > > u->fd = g_open(u->device_id, O_RDONLY) > ioch = g_io_channel_unix_new(u->fd); > > then use g_io_channel_read_chars() instead of read. > > I'm wonder if it is the beast approach or I'm missing any PA function > that fits better for this purpose. I'm not aware of any PA code that uses glib for this. module-pipe-sink seems to do most of the things you need so that might serve as a good starting point. -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] review+pull-request: Passthrough support
On Tue, 2011-04-19 at 15:03 -0500, pl bossart wrote: > I finally managed to figure out why eac3 wouldn't work in passthrough > mode. Apparently my HDMI receiver will only lock on eac3 data if the > AES0 control is set to 0x06 (non-audio, ie iec61937). > > ffmpeg -acodec copy -i csi_miami_5.1_256_spx.eac3 -f spdif outfile.pcm > aplay -Dhdmi:AES0=0x6 -fs16 -c2 -r192000 outfile.pcm > > the same file plays well through pulseaudio if I modifed default.conf to > [Mapping hdmi-stereo] > device-strings = hdmi:%f,AES0=0x06 > channel-map = left,right > priority = 4 > direction = output > > Somehow we need to find a way to set this AES0 byte when opening the > iec958 or hdmi device in the passthrough code, and reset it back to > 0x04 for PCM playback (should be fairly easy to do by looking at the > code of iecset in alsa-utils). Beats me why this was not needed for > plain ac3, but setting the audio bit is actually the correct thing to > do. If my reading is correct, this is something we should do for all formats anyway? > So far all the tests seem ok with the ffmpeg examples, with the > exception of two files: > - 7_pt_1: works well with ffmpeg, aplay but the sound is way too fast > with pulseaudio. Lots of rewind messages seen in PulseAudio. > - serenity_english_5.1_1536.eac3 file: no sound out, and again lots of > rewind messages (the receiver still shows the D+ logo though). The > same file converted with ffmpeg and played with aplay seems fine. > looks like a buffering issue more than a payloader problem really. Is the ALSA device correctly being configured to 192 kHz? -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH] filter-apply: Make housekeeping optional
Adds an autoclean option (defaults to TRUE) that controls whether
module-filter-apply cleans up unused modules or not. This is useful in
cases where you know that a filter will be used often and thus can avoid
overhead from repeated module load/unload.
---
src/modules/module-filter-apply.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/src/modules/module-filter-apply.c
b/src/modules/module-filter-apply.c
index d4bded5..12acc91 100644
--- a/src/modules/module-filter-apply.c
+++ b/src/modules/module-filter-apply.c
@@ -25,6 +25,7 @@
#include
#include
+#include
#include
#include
@@ -44,11 +45,14 @@ PA_MODULE_AUTHOR("Colin Guthrie");
PA_MODULE_DESCRIPTION("Load filter sinks automatically when needed");
PA_MODULE_VERSION(PACKAGE_VERSION);
PA_MODULE_LOAD_ONCE(TRUE);
+PA_MODULE_USAGE(_("autoclean="));
static const char* const valid_modargs[] = {
+"autoclean",
NULL
};
+#define DEFAULT_AUTOCLEAN TRUE
#define HOUSEKEEPING_INTERVAL (10 * PA_USEC_PER_SEC)
struct filter {
@@ -66,6 +70,7 @@ struct userdata {
*sink_input_proplist_slot,
*sink_input_unlink_slot,
*sink_unlink_slot;
+pa_bool_t autoclean;
pa_time_event *housekeeping_time_event;
};
@@ -152,6 +157,9 @@ static void housekeeping_time_callback(pa_mainloop_api*a,
pa_time_event* e, cons
static void trigger_housekeeping(struct userdata *u) {
pa_assert(u);
+if (!u->autoclean)
+return;
+
if (u->housekeeping_time_event)
return;
@@ -345,6 +353,12 @@ int pa__init(pa_module *m) {
u->core = m->core;
+u->autoclean = DEFAULT_AUTOCLEAN;
+if (pa_modargs_get_value_boolean(ma, "autoclean", &u->autoclean) < 0) {
+pa_log("Failed to parse autoclean value");
+goto fail;
+}
+
u->filters = pa_hashmap_new(filter_hash, filter_compare);
u->sink_input_put_slot =
pa_hook_connect(&m->core->hooks[PA_CORE_HOOK_SINK_INPUT_PUT], PA_HOOK_LATE,
(pa_hook_cb_t) sink_input_put_cb, u);
--
1.7.5.rc1
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] RFC: Filter module loader
On Tue, 2011-04-19 at 10:08 +0530, Arun Raghavan wrote: > On Fri, 2011-04-15 at 17:27 +0200, Colin Guthrie wrote: > > Hi, > > > > Here is my first draft of a filter module to automatically load > > equalizer and/or echo-cancel modules if automagically and in a manual > > but convenient way. > [...] > > Nice! Tested here and works well. :) Just thought of one case that isn't being handled - if the module is loaded in configuration, module-intended-roles seems to override the module-filter-* sinks. I suppose we could just handle this with some documentation in default.pa to make sure both of these aren't used together. Sort of orthogonal to this problem, and inspired by your proposal for routing - I'd like to have routing modules deal with lists of sinks rather than pick one sink and set it on the sink input. So each module that wants to modify routing can add/remove sinks from the sink list and reorder if required, so that the valid sinks are sorted in priority order. The core would then pick the first one that matches a format it wants to send. Functionally, this doesn't do a whole lot right now, but it will make routing modules a little more flexible. For example, the filter-apply module could add sinks to the top of the list, and then the filter-heuristics module would remove matching sinks from the list. Thoughts? -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] RFC: Filter module loader
On Fri, 2011-04-15 at 17:27 +0200, Colin Guthrie wrote: > Hi, > > Here is my first draft of a filter module to automatically load > equalizer and/or echo-cancel modules if automagically and in a manual > but convenient way. [...] Nice! Tested here and works well. :) > One thing that I've not really considered is how to deal with the fact > that echo-cancel is probably only needed when the external mic and > speakers are used so there may need to be more smarts added to deal > with this, but I'm not really all that clued up on when this should or > shouldn't be used. This one's going to be a pain to do right no matter what we do - even if when you know external speaker/mic aren't being used, you still don't know if the things that are connected will have echo or not. I think we're just going to have a global option (in paprefs?) and let people decide whether they want it or not. -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH] volume: Get more data from volume tests
This makes the volume tests run in two loops and print the minimum,
maximum and standard deviation of readings from the inner loop. This
makes it easier to reason out performance drops (i.e. algorithmic
problems vs. other system issues such as processor contention).
---
src/pulsecore/svolume_arm.c | 50 +-
src/pulsecore/svolume_mmx.c | 46 +++
src/pulsecore/svolume_orc.c | 62 +--
src/pulsecore/svolume_sse.c | 46 +++
4 files changed, 147 insertions(+), 57 deletions(-)
diff --git a/src/pulsecore/svolume_arm.c b/src/pulsecore/svolume_arm.c
index 42e8cbf..098f10e 100644
--- a/src/pulsecore/svolume_arm.c
+++ b/src/pulsecore/svolume_arm.c
@@ -130,6 +130,7 @@ static void pa_volume_s16ne_arm(int16_t *samples, int32_t
*volumes, unsigned cha
#define CHANNELS 2
#define SAMPLES 1022
#define TIMES 1000
+#define TIMES2 100
#define PADDING 16
static void run_test(void) {
@@ -140,6 +141,9 @@ static void run_test(void) {
int i, j, padding;
pa_do_volume_func_t func;
pa_usec_t start, stop;
+int k;
+pa_usec_t min = INT_MAX, max = 0;
+double s1 = 0, s2 = 0;
func = pa_get_volume_func(PA_SAMPLE_S16NE);
@@ -159,25 +163,45 @@ static void run_test(void) {
for (i = 0; i < SAMPLES; i++) {
if (samples[i] != samples_ref[i]) {
printf ("%d: %04x != %04x (%04x * %04x)\n", i, samples[i],
samples_ref[i],
- samples_orig[i], volumes[i % CHANNELS]);
+ samples_orig[i], volumes[i % CHANNELS]);
}
}
-start = pa_rtclock_now();
-for (j = 0; j < TIMES; j++) {
-memcpy(samples, samples_orig, sizeof(samples));
-pa_volume_s16ne_arm(samples, volumes, CHANNELS, sizeof(samples));
+for (k = 0; k < TIMES2; k++) {
+start = pa_rtclock_now();
+for (j = 0; j < TIMES; j++) {
+memcpy(samples, samples_orig, sizeof(samples));
+pa_volume_s16ne_arm(samples, volumes, CHANNELS, sizeof(samples));
+}
+stop = pa_rtclock_now();
+
+if (min > (stop - start)) min = stop - start;
+if (max < (stop - start)) max = stop - start;
+s1 += stop - start;
+s2 += (stop - start) * (stop - start);
}
-stop = pa_rtclock_now();
-pa_log_info("ARM: %llu usec.", (long long unsigned int) (stop - start));
+pa_log_info("ARM: %llu usec (min = %llu, max = %llu, stddev = %g).", (long
long unsigned int)s1,
+(long long unsigned int)min, (long long unsigned int)max,
sqrt(TIMES2 * s2 - s1 * s1) / TIMES2);
+
+min = INT_MAX; max = 0;
+s1 = s2 = 0;
+for (k = 0; k < TIMES2; k++) {
+start = pa_rtclock_now();
+for (j = 0; j < TIMES; j++) {
+memcpy(samples_ref, samples_orig, sizeof(samples));
+func(samples_ref, volumes, CHANNELS, sizeof(samples));
+}
+stop = pa_rtclock_now();
-start = pa_rtclock_now();
-for (j = 0; j < TIMES; j++) {
-memcpy(samples_ref, samples_orig, sizeof(samples));
-func(samples_ref, volumes, CHANNELS, sizeof(samples));
+if (min > (stop - start)) min = stop - start;
+if (max < (stop - start)) max = stop - start;
+s1 += stop - start;
+s2 += (stop - start) * (stop - start);
}
-stop = pa_rtclock_now();
-pa_log_info("ref: %llu usec.", (long long unsigned int) (stop - start));
+pa_log_info("ref: %llu usec (min = %llu, max = %llu, stddev = %g).", (long
long unsigned int)s1,
+(long long unsigned int)min, (long long unsigned int)max,
sqrt(TIMES2 * s2 - s1 * s1) / TIMES2);
+
+pa_assert_se(memcmp(samples_ref, samples, sizeof(samples)) == 0);
}
#endif
diff --git a/src/pulsecore/svolume_mmx.c b/src/pulsecore/svolume_mmx.c
index 421156e..7286b4a 100644
--- a/src/pulsecore/svolume_mmx.c
+++ b/src/pulsecore/svolume_mmx.c
@@ -241,6 +241,7 @@ static void pa_volume_s16re_mmx(int16_t *samples, int32_t
*volumes, unsigned cha
#define CHANNELS 2
#define SAMPLES 1022
#define TIMES 1000
+#define TIMES2 100
#define PADDING 16
static void run_test(void) {
@@ -251,6 +252,9 @@ static void run_test(void) {
int i, j, padding;
pa_do_volume_func_t func;
pa_usec_t start, stop;
+int k;
+pa_usec_t min = INT_MAX, max = 0;
+double s1 = 0, s2 = 0;
func = pa_get_volume_func(PA_SAMPLE_S16NE);
@@ -277,21 +281,39 @@ static void run_test(void) {
}
}
-start = pa_rtclock_now();
-for (j = 0; j < TIMES; j++) {
-memcpy(samples, samples_orig, sizeof(samples));
-pa_volume_s16ne_mmx(samples, volumes, CHANNELS, sizeof(samples));
+for (k = 0; k < TIMES2; k++) {
+start = pa_rtclock_now();
+for (j = 0; j < TIMES; j++) {
+memcpy(samples, samples_orig, sizeof(samples));
+pa_volume_s16ne_mmx(samples, volumes, CHANNELS, sizeof(samples));
+}
+s
Re: [pulseaudio-discuss] pa_simple_free
On Fri, 2011-04-08 at 21:12 +0900, patrick wrote: > Arun thank you very much for this! It works perfectly, it only means one > thing, our program is buggy. We are using a thread also (pthread), i am > not sure why, but PulseAudio stop at pa_mutex_lock. We cannot finish our > thread before PulseAudio finish his. Any advice is more than welcome. Sorry, nothing obvious comes to mind. Did you have any luck with this? -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] please explain me this recommendation
On Fri, 2011-04-15 at 11:40 +0200, Claude Frantz wrote: > Hello ! > > In many places, I have found the recommendation to set > > default-framents = 8 > default-fragment-size-msec = 5 > > in daemon.conf when using "old" software. Please explain me why. > Are there drawbacks when using more "modern" software ? Many thanks, In recent version, and by default, PulseAudio will dynamically adjust these values based on the latency requirements of the clients that are connected. Cheers, Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] review+pull-request: Passthrough support
On Wed, 2011-04-13 at 18:23 +0530, Arun Raghavan wrote: [...] > The changes needed to actually use this in GStreamer are also done, but > not upstream yet. I need to do some rebasing to make this stuff good to > push out, so details on this in a following mail. Okay, this is also pushed and good to test. I'll be pushing this out to master after the next round of gst* releases (which should happen in the next couple of weeks or so). For now, you'll need: * gstreamer from git master * gst-plugins-base from: http://git.collabora.co.uk/?p=user/arun/gst-plugins-base.git;a=shortlog;h=refs/heads/passthrough * gst-plugins-good from: http://git.collabora.co.uk/?p=user/arun/gst-plugins-good.git;a=shortlog;h=refs/heads/passthrough * gst-plugins-bad, gst-plugins-ugly, gst-ffmpeg built against the above would probably also be needed (for non-passthrough playback) With all but the top-most commit to gst-plugins-good, pulsesink will be plugged in passthrough mode when the sink supports the format of the input. The top-most commit on gst-plugins-good introduces a new pulsesinkbin element, which automatically reconfigures based on what formats are available on the sink we're connected to. So if you're playing AC3 in passthrough mode over S/PDIF and switch to analog out, it'll transparently plug in a decoder, and if you switch back to digital out, the decoder will be removed and passthrough mode will be enabled again. pulsesinkbin will be autoplugged if your app (or gst-launch) is using playbin2, but most applications totem/rhythmbox/... override the playbin2 audio sink, so there's some work pending before this just works with players. I'm happy to help if anyone runs into problems while testing. Cheers, Arun p.s.: for those of you who want to test but don't have a gstreamer-from-git setup already, jhbuild[1] or gst-uninstalled[2] should be useful. [1]: http://live.gnome.org/Jhbuild [2]: http://gstreamer.freedesktop.org/data/doc/gstreamer/head/faq/html/chapter-developing.html#developing-uninstalled-gstreamer ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] review+pull-request: Passthrough support
Hey folks, My passthrough work is now at a point where I think it's good to pull to master. All the core code for clients to signal that they are providing a compressed format, and sinks to signal what formats they support is there. The API is essentially the same as discussed earlier on-list, with some small tweaks along the way as necessary. Still pending are proper detection/signalling of available formats on ALSA devices is to be done (Colin's looking at some of the plumbing for S/PDIF, and HDMI ELD/EDID-based lookups are something that we need as well), and better handling of monitors (we suspend them for now, which works), and volumes (Tanu's got some on-going work on this). NOTE: given the above about ALSA, topmost patch should probably not be pulled, but is handy to have for testing. In addition to the passthrough branch, there is a passthrough-bt branch which has changes to the bluetooth sink to support streaming MP3 to headsets that support it. This also needs some work before being ready to pull. The changes needed to actually use this in GStreamer are also done, but not upstream yet. I need to do some rebasing to make this stuff good to push out, so details on this in a following mail. Comments, feedback will be very much appreciated. :) Cheers, Arun The following changes since commit aaab340d4e3c57d58755151310f59a0ee96554b1: bluetooth-device: fix rounding errors caused by few bt volume steps (2011-04-05 11:24:12 +0100) are available in the git repository at: git://git.collabora.co.uk/git/user/arun/pulseaudio.git passthrough Arun Raghavan (37): sink: Trivial typo fix sample: Use PA_SAMPLE_INVALID instead of numeric value core: Add a pa_format_info structure format: Add some properties and internal API sink: Extend API for compressed formats support core: Add extended stream API to support compressed formats format: Add convenience API to check if a format is PCM or not sink: Remove PASSTHROUGH flag tests: Add a trivial test for the extended API sink-input: Minor cleanups sink-input: Return NOTSUPPORTED if format negotiation fails sink-input: Don't assert on bad formats format: Avoid some code duplication sink: Fix leak in pa_sink_check_formats() sink-input: Kill passthrough streams if moving to an unsupported sink core: Fix some FIXMEs for the extended API alsa-mixer: Remove passthrough profiles sink: Trivial typo fix in comment core: Suspend monitor when a sink enters passthrough mode alsa: Reconfigure sink sample rate for passthrough inputs format: Const-ify some parameters format: Add some convenience functions for printing stream: Add API to get a stream's pa_format_info introspect: Get formats for sinks introspect: Get format of sink input format: Add a type for DTS core: Factor out passthrough checks into their own functions sink-input: Don't assert if passthrough connection fails sink-input: Don't restore volume for passthrough streams sink-input: Add a format-lost event format: Export pa_format_info_is_compatible in API format: Add correct sample spec conversion for E-AC3 sink-input: Provide more information to client when format is lost stream-restore: Check for readability before reading volume format: Extend properties to handle lists/ranges format: Add some convenience API for setting properties alsa: WIP AC3/E-AC3/DTS passthrough negotiation support Pierre-Louis Bossart (1): sink-input: Don't resample passthrough inputs PROTOCOL | 28 ++ configure.ac |8 +- po/POTFILES.in |1 + src/Makefile.am| 22 +- src/map-file | 19 + src/modules/alsa/alsa-sink.c | 110 +- .../mixer/paths/iec958-passthrough-output.conf | 19 - src/modules/alsa/mixer/profile-sets/default.conf |7 - src/modules/echo-cancel/module-echo-cancel.c |2 +- src/modules/module-combine.c |2 +- src/modules/module-device-manager.c|4 +- src/modules/module-equalizer-sink.c|2 +- src/modules/module-intended-roles.c| 10 +- src/modules/module-ladspa-sink.c |2 +- src/modules/module-loopback.c |2 +- src/modules/module-remap-sink.c|2 +- src/modules/module-sine.c |2 +- src/modules/module-stream-restore.c| 10 +- src/modules/module-virtual-sink.c |2 +- src/modules/rtp/module-rtp-recv.c |2 +- src/pulse/def.h
Re: [pulseaudio-discuss] [PATCH] stream-restore: Check for readability before reading volume
On Tue, 2011-04-12 at 13:11 +0530, Arun Raghavan wrote: > This avoids an assert in pa_sink_input_get_volume() when connecting a > passthrough stream. Based on Tanu's comments on the previous version of the patch, this one should be correct. -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH] stream-restore: Check for readability before reading volume
This avoids an assert in pa_sink_input_get_volume() when connecting a
passthrough stream.
---
src/modules/module-stream-restore.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/modules/module-stream-restore.c
b/src/modules/module-stream-restore.c
index 9c94583..c984f18 100644
--- a/src/modules/module-stream-restore.c
+++ b/src/modules/module-stream-restore.c
@@ -1168,7 +1168,7 @@ static void subscribe_callback(pa_core *c,
pa_subscription_event_type_t t, uint3
created_new_entry = FALSE;
}
-if (sink_input->save_volume) {
+if (sink_input->save_volume &&
pa_sink_input_is_volume_readable(sink_input)) {
pa_assert(sink_input->volume_writable);
entry.channel_map = sink_input->channel_map;
--
1.7.4.1
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] 2 minor issues noticed with padsp
On Thu, 2011-04-07 at 17:25 -0400, Drew Ogle wrote: > Hi, > > I have a really old application that uses oss interfaces, and noticed > that when attempting to run via padsp it would fail ( as opposed to > with aoss ). > After talking with Ford_Prefect in #pulseaudio, we narrowed down the > problem to protocol-native.c > Attached is a patch which allows padsp's get_sink_info call to success > on the server side ( drop-invalid-check ). > He mentioned that name is allowed to be null; which makes me think it > might be less confusing to just do a *name check and then no others. Ack from me on the first patch. > Additionally, I noticed that in padsp.c it was recieving two callbacks > in both sink and source_info_cb. As this appears to be the desired > behavior in introspect.c, I modified the _cb functions to only notify > if success was not already set. This second one can be tweaked so that we just drop the !si in both those conditions - don't need to chagne anything else. Cheers, Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] sink-input: Don't assert while trying to get non-readable volume
On Mon, 2011-04-11 at 09:46 +0300, Tanu Kaskinen wrote: > On Sun, 2011-04-10 at 16:52 +0530, Arun Raghavan wrote: > > Since no clients currently handle non-readable volumes, we handle this > > condition more gracefully (return PA_VOLUME_NORM). In the future, this > > could probably changed into an error return instead of an assert so that > > a non-conformant client doesn't bring the daemon down. > > When I added the assertion, the idea was that whatever code calls > pa_sink_input_get_volume() calls first > pa_sink_input_is_volume_readable(). And I at least tried to add those > checks everywhere. How are you able to hit the assertion? I connect with a passthrough stream and I hit this: Program received signal SIGABRT, Aborted. 0x72a96839 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 64return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig); (gdb) bt #0 0x72a96839 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x72a97b9a in abort () at abort.c:92 #2 0x77b8ea2b in pa_sink_input_assert_ref (i=0x7621e0, volume=0x7fffd5e6, absolute=false) at ./pulsecore/sink-input.h:246 #3 pa_sink_input_get_volume (i=0x7621e0, volume=0x7fffd5e6, absolute=false) at pulsecore/sink-input.c:1219 #4 0x7fffee451464 in subscribe_callback (c=, t=, idx=, userdata=0x627ec0) at modules/module-stream-restore.c:1175 #5 0x77b7306e in defer_cb (m=, de=, userdata=0x61d170) at pulsecore/core-subscribe.c:175 #6 0x77713e3f in dispatch_defer (m=0x61cf50) at pulse/mainloop.c:706 #7 pa_mainloop_dispatch (m=0x61cf50) at pulse/mainloop.c:922 #8 0x77714165 in pa_mainloop_iterate (m=0x61cf50, block=, retval=0x7fffdb0c) at pulse/mainloop.c:962 #9 0x77714210 in pa_mainloop_run (m=0x61cf50, retval=0x7fffdb0c) at pulse/mainloop.c:977 #10 0x0040c440 in main (argc=, argv=) at daemon/main.c:1135 > My current plan for non-readable volume is a slightly different, btw. > Instead of having a volume_readable property, I plan to have a > volume_enabled property. When volume_enabled is false, within the daemon > the volume is still readable and writable (unless volume_writable is > false), it just doesn't have any effect. This gets rid of the problem of > how to restore the old volume after the volume is re-enabled when > switching between passthrough and normal modes. To the clients this is > not a very visible change - they still can not read (or they get always > PA_VOLUME_NORM as the value) or write the sink volume when it's in the > passthrough mode. But this behavior is implemented within > protocol-native etc, not enforced by the core. Thid does seem to makes sense - modules /will/ have to consider how to handle the new situations, but that's a good thing. Cheers, Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH] sink-input: Don't assert while trying to get non-readable volume
Since no clients currently handle non-readable volumes, we handle this condition more gracefully (return PA_VOLUME_NORM). In the future, this could probably changed into an error return instead of an assert so that a non-conformant client doesn't bring the daemon down. --- src/pulsecore/sink-input.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/src/pulsecore/sink-input.c b/src/pulsecore/sink-input.c index ff562eb..323d4e7 100644 --- a/src/pulsecore/sink-input.c +++ b/src/pulsecore/sink-input.c @@ -1219,9 +1219,10 @@ pa_cvolume *pa_sink_input_get_volume(pa_sink_input *i, pa_cvolume *volume, pa_bo pa_sink_input_assert_ref(i); pa_assert_ctl_context(); pa_assert(PA_SINK_INPUT_IS_LINKED(i->state)); -pa_assert(pa_sink_input_is_volume_readable(i)); -if (absolute || !pa_sink_flat_volume_enabled(i->sink)) +if (!pa_sink_input_is_volume_readable(i)) +pa_cvolume_reset (volume, i->sample_spec.channels); +else if (absolute || !pa_sink_flat_volume_enabled(i->sink)) *volume = i->volume; else *volume = i->reference_ratio; -- 1.7.4.1 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] pa_simple_free
Hi, On Fri, 2011-04-08 at 03:15 +0900, patrick wrote: > > Does the parec-simple example work for you (it's part of the > > PulseAudio source tree). > > > > Hi Daniel, > > For first of all thank you for taking the time to help me track down our > problem. parec-simple is working (nicely quitting). So the problem must > be in this small code: http://pastebin.ubuntu.com/590602/ I modified your code to compile independently and it works fine here. http://paste.pocoo.org/show/367406/ Are you using the API differently from this in your code? -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] alsa-mixer: Add workaround for some USB headsets
On Wed, 2011-04-06 at 16:57 +1000, Luke Yelavich wrote: > On Wed, Apr 06, 2011 at 06:57:22AM EST, Colin Guthrie wrote: > > We'll likely push out stable-queue very soon. If you've got a fairly > > recent snapshot for Ubuntu already, then bumping the version to 0.9.23 > > should be uncontroversial (tho' version bumps may still be banned by > > policy regardless). > > > > What do you think? > > Given that beta 2 freeze is next Monday, and with each freeze things get > progressively more locked down, I only plan on taking the bugfix elements of > stable-queue. I understand the echo-cancel module and Lennart's new function > are fixes, but they introduce new functionality, so I will not be including > it in natty short of a crisis that require me to pull them in, and go begging > to the release team. For what it's worth, the echo-cancel module is off-by-default, with the main purpose of pushing it out being to get early-adopter testing from those who want to enable it (and know enough to do so manually from the command line). Cheers, Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] alignment trap and pulseaudio being kiled
On Tue, 2011-04-05 at 10:21 +0200, Daniel Mack wrote: > On Mon, Apr 4, 2011 at 8:45 PM, Baek Chang wrote: > > Hi, > > Trying to debug pulseaudio 0.9.22 and I am seeing some alignment trap > > warnings from kernel > > [ 1564.095562] Alignment trap: alsa-sink (5580) PC=0x2ab2ca3c > > Instr=0xe1ca00d0 Address=0x2af9302a FSR 0x011 > > [ 1564.095597] Alignment trap: alsa-sink (5580) PC=0x2ab2ca68 > > Instr=0xe0ca00f8 Address=0x2af9302a FSR 0x811 > > [ 1564.113377] Alignment trap: alsa-sink (5580) PC=0x2ab2ca3c > > Instr=0xe1ca00d0 Address=0x2af93032 FSR 0x011 > > [ 1564.122811] Alignment trap: alsa-sink (5580) PC=0x2ab2ca68 > > Instr=0xe0ca00f8 Address=0x2af93032 FSR 0x811 > > [ 1564.132240] Alignment trap: alsa-sink (5580) PC=0x2ab2ca3c > > Instr=0xe1ca00d0 Address=0x2af9303a FSR 0x011 > > [ 1564.141703] Alignment trap: alsa-sink (5580) PC=0x2ab2ca68 > > Instr=0xe0ca00f8 Address=0x2af9303a FSR 0x811 > > [ 1564.151195] Alignment trap: alsa-sink (5580) PC=0x2ab2ca3c > > Instr=0xe1ca00d0 Address=0x2af93042 FSR 0x011 > > [ 1564.160625] Alignment trap: alsa-sink (5580) PC=0x2ab2ca68 > > Instr=0xe0ca00f8 Address=0x2af93042 FSR 0x811 > > [ 1564.170065] Alignment trap: alsa-sink (5580) PC=0x2ab2ca3c > > Instr=0xe1ca00d0 Address=0x2af9304a FSR 0x011 > > I tried connecting to gdb and reproducing the issue, the problem is that > > pulseaudio doesn't crash, but eventually terminates. > > Any ideas on how to debug this? > > You can tell your kernel to terminate processes which cause an > alignment trap immediately: "echo 5 > /proc/cpu/alignment". That > should make gdb stop right at the instruction causing it. Also see > $kernelsrc/Documentation/arm/mem_alignment. But note that this setting > is for your whole system, and not done on a per-process level. > > However, I dare to doubt that the alignment trap is your problem after > all. Such exceptions are normally just silently fixed in the > background, and the only effect you could possibly see is performance > drawbacks. Anyway, it would be nice to fix them. Also, if you haven't already, do take a look at http://pulseaudio.org/wiki/Community#BugsPatchesTranslations for instructions on running PulseAudio in gdb. -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] sbc_math.h: add explicit check for ARMv6 instructions
[stripping linux-bluetooth from to-list since this is PA-specific] On Wed, 2011-03-30 at 20:42 +0300, Luiz Augusto von Dentz wrote: > Hi Colin, > > On Tue, Mar 29, 2011 at 1:21 PM, Colin Guthrie wrote: > > 'Twas brillig, and Paul Menzel at 29/03/11 00:00 did gyre and gimble: > >> commit b676f89d8579c7ec1629892342a330f1e4c35657 > >> Author: Colin Guthrie > >> Date: Sun Mar 20 11:44:53 2011 + > >> > >> bluetooth: Run 'make update-sbc' > >> > >> Note that changes to ipc.h from 8f3ef04b had to be manually > >> reapplied. > >> > > > > I ran this after checking with Luiz first. > > > > I've asked that the local changes to our ipc.h were pushed upstream > > after doing so to but not sure of the status of that, Luiz, I think I > > included a specific patch in the last mail... let me know if you want it > > again :) > > I think it is better to add the a2dp-codecs.h header present on BlueZ > to PA too and remove the definitions Ive added to ipc.h, this should > make it easier to sync things. I just need some free time to make this > happen :D I needed to do this before pushing out MP3 support in a while anyway, so sent a patch. I notice there's a bunch of similar defines for sample rate etc. in ipc.h and a2dp-codecs.h, so maybe something that could be consolidated upstream to prevent confusion. Cheers, Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH] bluetooth: Pull a2dp-codecs.h grom BlueZ
This pulls a2dp-codecs.h from BlueZ which contains the capabilities
structures for SBC and MPEG. We currently have these manually added to
ipc.h, so pulling this header makes our files identical to upstream.
---
src/Makefile.am |2 +-
src/modules/bluetooth/a2dp-codecs.h | 116 +++
src/modules/bluetooth/bluetooth-util.c |8 +-
src/modules/bluetooth/ipc.h | 28 --
src/modules/bluetooth/module-bluetooth-device.c |8 +-
5 files changed, 123 insertions(+), 39 deletions(-)
create mode 100644 src/modules/bluetooth/a2dp-codecs.h
diff --git a/src/Makefile.am b/src/Makefile.am
index f3717ce..a7fc1ca 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -1851,7 +1851,7 @@ libbluetooth_ipc_la_SOURCES = modules/bluetooth/ipc.c
modules/bluetooth/ipc.h
libbluetooth_ipc_la_LDFLAGS = -avoid-version
libbluetooth_ipc_la_LIBADD = $(AM_LIBADD) libpulsecore-@PA_MAJORMINOR@.la
libpulsecommon-@PA_MAJORMINOR@.la libpulse.la
libbluetooth_ipc_la_CFLAGS = $(AM_CFLAGS)
-BLUETOOTH_IPC_FILES = $(subst
modules/bluetooth/,,$(libbluetooth_ipc_la_SOURCES)) rtp.h
+BLUETOOTH_IPC_FILES = $(subst
modules/bluetooth/,,$(libbluetooth_ipc_la_SOURCES)) rtp.h a2dp-codecs.h
libbluetooth_util_la_SOURCES = modules/bluetooth/bluetooth-util.c
modules/bluetooth/bluetooth-util.h
libbluetooth_util_la_LDFLAGS = -avoid-version
diff --git a/src/modules/bluetooth/a2dp-codecs.h
b/src/modules/bluetooth/a2dp-codecs.h
new file mode 100644
index 000..e44634e
--- /dev/null
+++ b/src/modules/bluetooth/a2dp-codecs.h
@@ -0,0 +1,116 @@
+/*
+ *
+ * BlueZ - Bluetooth protocol stack for Linux
+ *
+ * Copyright (C) 2006-2010 Nokia Corporation
+ * Copyright (C) 2004-2010 Marcel Holtmann
+ *
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program 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 General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ */
+
+#define A2DP_CODEC_SBC 0x00
+#define A2DP_CODEC_MPEG12 0x01
+#define A2DP_CODEC_MPEG24 0x02
+#define A2DP_CODEC_ATRAC 0x03
+
+#define SBC_SAMPLING_FREQ_16000(1 << 3)
+#define SBC_SAMPLING_FREQ_32000(1 << 2)
+#define SBC_SAMPLING_FREQ_44100(1 << 1)
+#define SBC_SAMPLING_FREQ_480001
+
+#define SBC_CHANNEL_MODE_MONO (1 << 3)
+#define SBC_CHANNEL_MODE_DUAL_CHANNEL (1 << 2)
+#define SBC_CHANNEL_MODE_STEREO(1 << 1)
+#define SBC_CHANNEL_MODE_JOINT_STEREO 1
+
+#define SBC_BLOCK_LENGTH_4 (1 << 3)
+#define SBC_BLOCK_LENGTH_8 (1 << 2)
+#define SBC_BLOCK_LENGTH_12(1 << 1)
+#define SBC_BLOCK_LENGTH_161
+
+#define SBC_SUBBANDS_4 (1 << 1)
+#define SBC_SUBBANDS_8 1
+
+#define SBC_ALLOCATION_SNR (1 << 1)
+#define SBC_ALLOCATION_LOUDNESS1
+
+#define MPEG_CHANNEL_MODE_MONO (1 << 3)
+#define MPEG_CHANNEL_MODE_DUAL_CHANNEL (1 << 2)
+#define MPEG_CHANNEL_MODE_STEREO (1 << 1)
+#define MPEG_CHANNEL_MODE_JOINT_STEREO 1
+
+#define MPEG_LAYER_MP1 (1 << 2)
+#define MPEG_LAYER_MP2 (1 << 1)
+#define MPEG_LAYER_MP3 1
+
+#define MPEG_SAMPLING_FREQ_16000 (1 << 5)
+#define MPEG_SAMPLING_FREQ_22050 (1 << 4)
+#define MPEG_SAMPLING_FREQ_24000 (1 << 3)
+#define MPEG_SAMPLING_FREQ_32000 (1 << 2)
+#define MPEG_SAMPLING_FREQ_44100 (1 << 1)
+#define MPEG_SAMPLING_FREQ_48000 1
+
+#define MAX_BITPOOL 64
+#define MIN_BITPOOL 2
+
+#if __BYTE_ORDER == __LITTLE_ENDIAN
+
+typedef struct {
+ uint8_t channel_mode:4;
+ uint8_t frequency:4;
+ uint8_t allocation_method:2;
+ uint8_t subbands:2;
+ uint8_t block_length:4;
+ uint8_t min_bitpool;
+ uint8_t max_bitpool;
+} __attribute__ ((packed)) a2dp_sbc_t;
+
+typedef struct {
+ uint8_t channel_mode:4;
+ uint8_t crc:1;
+ uint8_t layer:3;
+ uint8_t frequency:6;
+ uint8_t mpf:1;
+ uint8_t rfa:1;
+ uint16_t bitrate;
+} __attribute__ ((packed)) a2dp_mpeg_t;
+
+#elif __BYTE_ORDER == __BIG_ENDIAN
+
+typedef struct {
+ uint8_t frequency:4;
+ uint8_t channel_mode:4;
+ uint8_t block_length:4;
+ uint8_t subbands:2;
+ uint8_t allocation_method:2;
+ uint8_t min_bitpool;
[pulseaudio-discuss] [PATCH] cork-on-phone: Handle sink-inputs with NULL sinks
It's possible that by the time we receive the unlink hook, the given sink-input's sink is set to NULL. Handle this gracefully. --- src/modules/module-cork-music-on-phone.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/src/modules/module-cork-music-on-phone.c b/src/modules/module-cork-music-on-phone.c index b629f06..5e6aa64 100644 --- a/src/modules/module-cork-music-on-phone.c +++ b/src/modules/module-cork-music-on-phone.c @@ -138,6 +138,9 @@ static pa_hook_result_t process(struct userdata *u, pa_sink_input *i, pa_bool_t !pa_streq(role, "video")) return PA_HOOK_OK; +if (!i->sink) +return PA_HOOK_OK; + cork = shall_cork(i->sink, create ? NULL : i); apply_cork(u, i->sink, create ? NULL : i, cork); -- 1.7.4.1 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Getting rid of annoying (but harmless) linking warnings
On Sun, 2011-03-27 at 11:29 +0100, Colin Guthrie wrote: > Hiya, > > 'Twas brillig, and Maarten Bosmans at 26/03/11 11:28 did gyre and gimble: > > Check whether output of > > pkg-config --libs dbus-1 > > pkg-config --libs sndfile > > contains any offensive parameters. > > > > If there is anything out of the ordinary, cat libpulsecommon-1.0.la > > could also reveal something, as I suspect your problem has more to do > > with libtool than with autotools. > > OK, this took me a while to chase down, but it turned out to be coming > from two different places, and required fixes in three other packages on > my system. No change in PA needed. Thanks so much for tracking this down! It's awesome to build without all the warning floodspam. Excellent start to week. :) > 1. libasyncns. It's libasyncns.pc file was giving out bogus libdir > flags. That is fixed with this patch (Lennart, please commit this to > upstream libasyncns please!) Lennart: don't forget to fix includedir as well, while you're at it. > http://svnweb.mageia.org/packages/cauldron/libasyncns/current/SOURCES/libasyncns-0.8-libdir.patch?revision=77953&view=markup > > 2. flac (libFLAC) is a bit weird. It detects ogg support automatically, > but if you do not pass an appropriate configure flag to it, will include > /usr/lib in it's .la files. I applied the following patch to ensure that > the ogg.m4 file was the same as the one provided by libogg itself > (although strictly speaking this is not needed): > http://svnweb.mageia.org/packages/cauldron/flac/current/SOURCES/flac-1.2.1-ogg-m4.patch?revision=77968&view=markup > > And then ensured the --with-ogg argument was passed to configure. By > passing this argument, the /usr/lib path was not leaked. Go figure. > > 3. I rebuilt libsndfile as this pulled in the leaky libdir path from > flac in it's libsndfile.la file. > > > After all that, everything is nice and quiet :) Pushed both of these to Gentoo as well. :) Cheers, Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] .gitignore: Add ChangeLog and src/envelope-test to the ignore list
On Sun, 2011-03-27 at 17:39 +0300, Tanu Kaskinen wrote: [...] > diff --git a/src/.gitignore b/src/.gitignore > index e56c225..1f959ec 100644 > --- a/src/.gitignore > +++ b/src/.gitignore > @@ -66,3 +66,4 @@ start-pulseaudio-x11 > start-pulseaudio-kde > vector-test > *-symdef.h > +envelope-test This test has been removed. Probably a stale binary in your tree. -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] svolume_orc.c: error: line 67: unknown directive: .longparam
On Fri, 2011-03-25 at 12:21 +0100, Paul Menzel wrote: [...] > I verified that it works with Orc 0.4.10. I went with 0.4.11 because I had some vague recollection of hitting a bug in 0.4.10 and didn't want to take a chance. Cheers, Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH] build: Bump Orc dependency to 0.4.11
0.4.9 errors out at compile time, and might as well bump to 0.4.11 since that's the version being tested with and has been around for a while now. Thanks to Paul Menzel for pointing this out. --- configure.ac |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/configure.ac b/configure.ac index 5a1fde6..74dfe23 100644 --- a/configure.ac +++ b/configure.ac @@ -1417,7 +1417,7 @@ fi AM_CONDITIONAL([HAVE_FFTW], [test "x$HAVE_FFTW" = "x1"]) ### ORC (optional) ### -ORC_CHECK([0.4.9]) +ORC_CHECK([0.4.11]) ### Build and Install man pages ### AC_ARG_ENABLE(manpages, -- 1.7.4.1 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [solved, invalid] modules/bluetooth/sbc/sbc_primitives.h:41:22: error: expected ':', ',', '; ', '}' or '__attribute__' before 'X'
On Fri, 2011-03-25 at 08:07 +0100, Paul Menzel wrote: > Am Freitag, den 25.03.2011, 11:10 +0530 schrieb Arun Raghavan: > > On Thu, 2011-03-24 at 23:20 +0100, Paul Menzel wrote: > > > > I get the following error with latest master (a9c8f904). > > > > > > CC libbluetooth_sbc_la-sbc.lo > > > In file included from > > > modules/bluetooth/sbc/sbc_primitives_armv6.h:30:0, > > > from modules/bluetooth/sbc/sbc_math.h:27, > > > from modules/bluetooth/sbc/sbc.c:46: > > > modules/bluetooth/sbc/sbc_primitives.h:41:22: error: expected > > > ':', ',', ';', '}' or '__attribute__' before 'X' > > > modules/bluetooth/sbc/sbc.c: In function 'sbc_synthesize_four': > > > [...] > > > modules/bluetooth/sbc/sbc.c: In function > > > 'sbc_get_implementation_info': > > > modules/bluetooth/sbc/sbc.c:1216:24: error: 'struct > > > sbc_encoder_state' has no member named 'implementation_info' > > > modules/bluetooth/sbc/sbc.c:1217:1: warning: control reaches end > > > of non-void function [-Wreturn-type] > > > make[3]: *** [libbluetooth_sbc_la-sbc.lo] Error 1 > > > make[3]: Leaving directory > > > `/oe/build-minimal-uclibc/minimal-uclibc-dev/work/armv7a-oe-linux-uclibceabi/pulseaudio-0.9.22+git-r11.1-r0+a9c8f904b0c4a03e7bff004c103aa5910f8bea3d/git/src' > > > make[2]: *** [all] Error 2 > > > make[2]: Leaving directory > > > `/oe/build-minimal-uclibc/minimal-uclibc-dev/work/armv7a-oe-linux-uclibceabi/pulseaudio-0.9.22+git-r11.1-r0+a9c8f904b0c4a03e7bff004c103aa5910f8bea3d/git/src' > > > make[1]: *** [all-recursive] Error 1 > > > make[1]: Leaving directory > > > `/oe/build-minimal-uclibc/minimal-uclibc-dev/work/armv7a-oe-linux-uclibceabi/pulseaudio-0.9.22+git-r11.1-r0+a9c8f904b0c4a03e7bff004c103aa5910f8bea3d/git' > > > > > > I am using OpenEmbedded with `minimal` using EGLIBC or `minimal-uclibc` > > > using uClibc for `MACHINE = "beagleboard"`. > > > > > > Unfortunately I do not know what syntax error is causing this. > > > > > > modules/bluetooth/sbc/sbc_primitives.h:41:22: error: expected > > > ':', ',', ';', '}' or '__attribute__' before 'X' > > > > I'm guessing that you've patched sbc_math.h with my earlier patch? If > > yes, looks like you need to add a > > > > #include "sbc_tables.h" > > > > in sbc_primitives.h since it depends on some defines from that file. I > > guess this ends up happening in all the other instances where that file > > is used. > > I am sorry. I had still two patches applied (your `sbc_math.h` and a > revert of 4cd90d9e32ca9a23e3c0f7615974ea0c55ff3e49) which I overlooked. > > > In the mean time, I'll try to unbreak my cross-compile > > environment so I can test this stuff locally as well. Gentoo crossdev. dbus-glib ebuild is broken while cross-compiling, so I couldn't even get bluez. Found a fix, so hoping to make some progress. -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] modules/bluetooth/sbc/sbc_primitives.h:41:22: error: expected ':', ',', '; ', '}' or '__attribute__' before 'X'
On Thu, 2011-03-24 at 23:20 +0100, Paul Menzel wrote: > Dear PulseAudio folks, > > > I get the following error with latest master (a9c8f904). > > CC libbluetooth_sbc_la-sbc.lo > In file included from > modules/bluetooth/sbc/sbc_primitives_armv6.h:30:0, > from modules/bluetooth/sbc/sbc_math.h:27, > from modules/bluetooth/sbc/sbc.c:46: > modules/bluetooth/sbc/sbc_primitives.h:41:22: error: expected ':', > ',', ';', '}' or '__attribute__' before 'X' > modules/bluetooth/sbc/sbc.c: In function 'sbc_synthesize_four': > [...] > modules/bluetooth/sbc/sbc.c: In function > 'sbc_get_implementation_info': > modules/bluetooth/sbc/sbc.c:1216:24: error: 'struct > sbc_encoder_state' has no member named 'implementation_info' > modules/bluetooth/sbc/sbc.c:1217:1: warning: control reaches end of > non-void function [-Wreturn-type] > make[3]: *** [libbluetooth_sbc_la-sbc.lo] Error 1 > make[3]: Leaving directory > `/oe/build-minimal-uclibc/minimal-uclibc-dev/work/armv7a-oe-linux-uclibceabi/pulseaudio-0.9.22+git-r11.1-r0+a9c8f904b0c4a03e7bff004c103aa5910f8bea3d/git/src' > make[2]: *** [all] Error 2 > make[2]: Leaving directory > `/oe/build-minimal-uclibc/minimal-uclibc-dev/work/armv7a-oe-linux-uclibceabi/pulseaudio-0.9.22+git-r11.1-r0+a9c8f904b0c4a03e7bff004c103aa5910f8bea3d/git/src' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory > `/oe/build-minimal-uclibc/minimal-uclibc-dev/work/armv7a-oe-linux-uclibceabi/pulseaudio-0.9.22+git-r11.1-r0+a9c8f904b0c4a03e7bff004c103aa5910f8bea3d/git' > > I am using OpenEmbedded with `minimal` using EGLIBC or `minimal-uclibc` > using uClibc for `MACHINE = "beagleboard"`. > > Unfortunately I do not know what syntax error is causing this. > > modules/bluetooth/sbc/sbc_primitives.h:41:22: error: expected ':', > ',', ';', '}' or '__attribute__' before 'X' I'm guessing that you've patched sbc_math.h with my earlier patch? If yes, looks like you need to add a #include "sbc_tables.h" in sbc_primitives.h since it depends on some defines from that file. I guess this ends up happening in all the other instances where that file is used. In the mean time, I'll try to unbreak my cross-compile environment so I can test this stuff locally as well. Cheers, Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 1/2] pactl: Accept more volume specification formats
On Thu, 2011-03-24 at 13:07 +, Colin Guthrie wrote: > 'Twas brillig, and Maarten Bosmans at 24/03/11 12:44 did gyre and gimble: > > 2011/3/24 Maarten Bosmans : > >> With this you can specify the volume with 6554, 10%, 0.001 or -60dB, > >> all resulting in the same volume change. > > > > I was also going to add relative volumes, such as +3dB and -5%, by > > detecting a + or - sign in the volume. But that clashes with the > > absolute dB scale (insofar a dB can ever be absolute) that can also be > > negative. > > > > Any suggestions for graceful handling of this? > > How about if the first letter of the volume change is an "i" or a "d" > then this indicated increment or decrement relative volume? > > It's not as clean as the +/- labelling sadly but such is life. > > Alternatively your absolute dB volumes could be specified as "60-dB" or > "7+dB" (where 7dB implies "7+dB")... That way the prefix +/- notation > could be used for relative adjustments. The only downside there is that > setting absolute dB volumes is more confusing (you'd never need to use > anything other than XdB for relative adjustments anyway). > > Personally I'd go for the later as I think relative adjustments are > probably more common, so it's syntax should be "neatest", but I could be > very wrong :D Or maybe just do this as a separate set-volume-step command (or -increment or something better named)? -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 2/2] Move compile-time checks around pa_run_from_build_tree to core-util
On Thu, 2011-03-24 at 11:46 +0100, Maarten Bosmans wrote: [...] > I think only compiling that on developer builds and inlining return > FALSE for normal, e.g. distro builds makes sense. However __OPTIMIZE__ > is not a good differentiator here. The callers all seem to be initialisation routines only, so why not just let it be called in distro and manual builds? -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] svolume_orc.c: error: line 67: unknown directive: .longparam
On Mon, 2011-03-21 at 00:06 +0100, Paul Menzel wrote: > Dear PulseAudio folks, [...] > I guess it has something to do with > > commit 4cd90d9e32ca9a23e3c0f7615974ea0c55ff3e49 > Author: Arun Raghavan > Date: Mon Oct 25 17:59:08 2010 +0100 > > volume: Add Orc-based optimised volume scaling > > This adds volume scaling for 1- and 2-channel software volume > scaling > using Orc. While testing the MMX and SSE backends on a Core2, I > see an > ~2x performance benefit over the hand-rolled MMX and SSE code. > Since I > haven't been able to test on other architectures, the Orc code is > only > used when MMX/SSE* is present. This can be changed in the future > after > testing on AMD and ARM machines. > > but I do not know anything about this. > > I am using OpenEmbedded with `minimal` or `minimal-uclibc` for `MACHINE > = "at91sam9260ek"`. ORCC 0.4.9 is used on this system. Could you try with Orc 0.4.10? Unfortunately, I don't have a quick way to downgrade my local Orc version to verify? If this is not possible, we can just bump the patch to 0.4.11, which was released a while ago (and is what I'm using). BTW, for 0.9.22 and current stable-queue, the Orc stuff will not get used for anything on ARM. Cheers, Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 2/2] Move compile-time checks around pa_run_from_build_tree to core-util
On Tue, 2011-03-22 at 16:06 +0100, Maarten Bosmans wrote: > Is there a better way than > #if defined(__linux__) && !defined(__OPTIMIZE__) > to check for a debug build? By default the CFLAGS contain -g -O2, so > __OPTIMIZE__ will not be defined and running uninstalled does not > work. Lennart might be able to answer this better, but to me it sounds like we should just drop the !__OPTIMIZE__ bit. -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] Get rid of some warnings
On Sun, 2011-03-20 at 22:56 +0100, Maarten Bosmans wrote: > 2011/3/20 Colin Guthrie : > > 'Twas brillig, and Maarten Bosmans at 19/03/11 15:26 did gyre and gimble: > >> Mostly warnings about unused stuff. > >> Furthermore, the first hunk is a fix for the change in 177948a6. > >> Finally, comment in AEC_dtd was translated and the code simplified > >> slightly. > > > > Thanks :) > > > >> CC module_echo_cancel_la-adrian-aec.lo > >> modules/echo-cancel/adrian-aec.h:360:15: warning: ‘AEC_getambient’ defined > >> but not used [-Wunused-function] > >> modules/echo-cancel/adrian-aec.h:368:14: warning: ‘AEC_setgain’ defined > >> but not used [-Wunused-function] > >> modules/echo-cancel/adrian-aec.h:374:14: warning: ‘AEC_setaes’ defined but > >> not used [-Wunused-function] > >> modules/echo-cancel/adrian-aec.h:377:16: warning: ‘AEC_max_dotp_xf_xf’ > >> declared ‘static’ but never defined [-Wunused-function] > > > > Is the Adrian code ours or is it external in some capacity. Arun, if > > it's external and we will update it periodically, can you do the > > necessary to push where it needs to go? (Obviously the PA_GCC_UNUSED > > cannot be pushed anywhere). > > I checked that there were already a lot of changes in git after the > inital import, and Arun seems to confirm. > Arun: what is the license of those files?, it doesn't really say in > the header. May be a audit of all files/licenses should be done in > general? There's a note about it at the bottom of LICENSE in the top directory. Maybe we should add something similar for the bluez bits as well. Cheers, Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] Get rid of some warnings
On Sun, 2011-03-20 at 13:12 +, Colin Guthrie wrote: > 'Twas brillig, and Maarten Bosmans at 19/03/11 15:26 did gyre and gimble: > > Mostly warnings about unused stuff. > > Furthermore, the first hunk is a fix for the change in 177948a6. > > Finally, comment in AEC_dtd was translated and the code simplified slightly. > > Thanks :) > > > CC module_echo_cancel_la-adrian-aec.lo > > modules/echo-cancel/adrian-aec.h:360:15: warning: ‘AEC_getambient’ defined > > but not used [-Wunused-function] > > modules/echo-cancel/adrian-aec.h:368:14: warning: ‘AEC_setgain’ defined but > > not used [-Wunused-function] > > modules/echo-cancel/adrian-aec.h:374:14: warning: ‘AEC_setaes’ defined but > > not used [-Wunused-function] > > modules/echo-cancel/adrian-aec.h:377:16: warning: ‘AEC_max_dotp_xf_xf’ > > declared ‘static’ but never defined [-Wunused-function] > > Is the Adrian code ours or is it external in some capacity. Arun, if > it's external and we will update it periodically, can you do the > necessary to push where it needs to go? (Obviously the PA_GCC_UNUSED > cannot be pushed anywhere). The upstream code isn't actively developed, and if it does, I'm going to have to do a manual merge anyway (since the original code was C++). So all good here. :) Cheers, Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [WIP] Passthrough support
On Sat, 2011-03-19 at 18:04 -0600, Kelly Anderson wrote: > On 03/16/11 10:48, Arun Raghavan wrote: > > On Wed, 2011-03-16 at 11:19 +0530, Arun Raghavan wrote: > > [...] > >> It will work, but not with paplay, only with the extended API when you > >> create a non-PCM stream. I will rationalise the check for passthrough > >> sink inputs in a bit, but for now, could you change the checks (there > > I've pushed a more comprehensive fix, so you shouldn't need to change > > that line and using paplay should work for you. > > > > -- Arun > > > Arun, > > Hey, I just got around to testing without the following patch. It > doesn't work. I also didn't see any recent checkins in the passthrough > tree that would seem to affect this. Is it possible the fix didn't get > pushed? Yep. :| Pushed now. Cheers, Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH 2/2] bluetooth: Fix alignment warning
While it seems to be common practice to just work around the cast to
integer and assume alignment is fine, let's play it safe and do it right
by memcpy'ing.
---
src/modules/bluetooth/ipc.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/modules/bluetooth/ipc.c b/src/modules/bluetooth/ipc.c
index dcecad8..fdca7a3 100644
--- a/src/modules/bluetooth/ipc.c
+++ b/src/modules/bluetooth/ipc.c
@@ -106,8 +106,11 @@ int bt_audio_service_get_data_fd(int sk)
for (cmsg = CMSG_FIRSTHDR(&msgh); cmsg != NULL;
cmsg = CMSG_NXTHDR(&msgh, cmsg)) {
if (cmsg->cmsg_level == SOL_SOCKET
- && cmsg->cmsg_type == SCM_RIGHTS)
- return (*(int *) CMSG_DATA(cmsg));
+ && cmsg->cmsg_type == SCM_RIGHTS) {
+ int fd;
+ memcpy(&fd, CMSG_DATA(cmsg), sizeof(int));
+ return fd;
+ }
}
errno = EINVAL;
--
1.7.4.1
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH 1/2] daemon: Fix missing include - cpu-orc.h
--- src/daemon/main.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/src/daemon/main.c b/src/daemon/main.c index 533c4c3..f7aed51 100644 --- a/src/daemon/main.c +++ b/src/daemon/main.c @@ -95,6 +95,7 @@ #endif #include #include +#include #include "cmdline.h" #include "cpulimit.h" -- 1.7.4.1 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] Couple of minor warning fixes
Since Maarten's declared war on warnings, thought I'd pitch in with a couple of fixes too. :) The first one is a boo-boo from my Orc work, and the second might be contentious to some (but is right imho). Cheers, Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] sbc_math.h: add explicit check for ARMv6 instructions
Hi Paul,
On Wed, 2011-02-23 at 01:07 +0530, Arun Raghavan wrote:
[...]
> The correct fix for this, imo, is in bluez (there is a new
> sbc_primitives_armv6.h that can probably be used at least as a
> template). We need to do an sbc-udpate on the PA side anyway, and can
> pull this when we do.
Could you see if the attached patch works for you? If it does, I can
push this to the bluez folks.
Cheers,
Arun
diff --git a/src/modules/bluetooth/sbc/sbc_math.h b/src/modules/bluetooth/sbc/sbc_math.h
index b87bc81..35d5dcc 100644
--- a/src/modules/bluetooth/sbc/sbc_math.h
+++ b/src/modules/bluetooth/sbc/sbc_math.h
@@ -23,6 +23,8 @@
*
*/
+#include "sbc_primitives_armv6.h"
+
#define fabs(x) ((x) < 0 ? -(x) : (x))
/* C does not provide an explicit arithmetic shift right but this will
always be correct and every compiler *should* generate optimal code */
@@ -47,7 +49,7 @@ typedef int32_t sbc_fixed_t;
#define SBC_FIXED_0(val) { val = 0; }
#define MUL(a, b)((a) * (b))
-#ifdef __arm__
+#ifdef SBC_HAVE_THUMB2
#define MULA(a, b, res) ({\
int tmp = res; \
__asm__(\
diff --git a/src/modules/bluetooth/sbc/sbc_primitives_armv6.h b/src/modules/bluetooth/sbc/sbc_primitives_armv6.h
index 1862aed..e70469a 100644
--- a/src/modules/bluetooth/sbc/sbc_primitives_armv6.h
+++ b/src/modules/bluetooth/sbc/sbc_primitives_armv6.h
@@ -38,6 +38,12 @@
#define SBC_HAVE_ARMV6 1
#endif
+#if defined(__ARM_ARCH_6T2__ ) || defined(__ARM_ARCH_7__) || \
+ defined(__ARM_ARCH_7A__) || defined(__ARM_ARCH_7R__) || \
+ defined(__ARM_ARCH_7M__)
+#define SBC_HAVE_THUMB2 1
+#endif
+
#if !defined(SBC_HIGH_PRECISION) && (SCALE_OUT_BITS == 15) && \
defined(__GNUC__) && defined(SBC_HAVE_ARMV6) && \
defined(__ARM_EABI__) && !defined(__thumb__) && \
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [WIP] Passthrough support
H Luiz, On Tue, 2011-03-15 at 18:37 -0300, Luiz Augusto von Dentz wrote: > Hi, > > On Tue, Mar 15, 2011 at 5:40 PM, pl bossart wrote: > >> I would suggest to use the new API to implement audio passthrough for > >> bluetooth devices, it is very likely the we will be disabling unix > >> socket IPC in BlueZ. What I would do is, if audio passthrough is > >> supported then PA register a mp3 endpoint and try to configure both > >> sbc and mp3 simultaneously (only one active at time) when possible so > >> we can quickly switch between codecs. > > > > Luiz, what is the time frame for removal of this socket IPC? Will it > > still be supported in Meego 1.2, 1.3, etc.? I don't disagree this is > > the right thing to do, I am just wondering if we would run into some > > integration issues that would actually delay the availability of MP3 > > passthrough by moving too quickly. Or maybe we can have the two > > approaches supported and remove this initial version at a later time? > > Currently the 2 API work side by side, in fact we should already be > able to use on MeeGo 1.2, for MeeGo 1.3 we should probably be moving > for BlueZ 5.x which afaik will remove the unix socket IPC completely > (Marcel can tell you the exact plan), so IMO we should try to > prioritize the Media API solution which btw is what currently > use/qualify in harmattan. Thanks for the feeedback - I wanted to get this up and running as soon as I could, so I just went with the method being used in PA now. Can you please translate that into a time frame in dates? We should probably try to figure out what API we want to ship as the on-by-default for the next PA release (and if it's the Media API, turn it on in master asap to get more testing and flush out any issues). Cheers, Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [WIP] Passthrough support
On Wed, 2011-03-16 at 11:19 +0530, Arun Raghavan wrote: [...] > It will work, but not with paplay, only with the extended API when you > create a non-PCM stream. I will rationalise the check for passthrough > sink inputs in a bit, but for now, could you change the checks (there I've pushed a more comprehensive fix, so you shouldn't need to change that line and using paplay should work for you. -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [WIP] Passthrough support
On Tue, 2011-03-15 at 17:36 -0500, pl bossart wrote: > > I pushed your change along with a fix for the assert you saw to my tree > > as well. > > I tested the latest batch of patches with AC3/SPDIF this time. Works > well in general, however I found some interesting points: > - in Rhythmbox, the passthrough mode is only enabled if the first file > of playlist is compressed. If you start with PCM/WAV, it always uses > the PCM mode. Are you using the crossfading backend? If yes, that won't work since they create their own pipeline with a volume element in between to do the crossfades. With the non-crossfading backend, I see it setting up an MP3 stream when it can and PCM when it can't. > - in Totem, the passthrough mode works when the visual effects are > disabled. I see a nice DD on my receiver...However the playback stops > if you play with the volume slider. I get a pop-up error window saying > 'an error occurred: pa_stream_set_sink_input_volume(): invalid > argument' Ah, I hadn't tried this out. We should be handling this more gracefully right now - will put this on my TODO list. > On a related note, maybe we want to change the approach to volume > control. Depending on the sink, there might be ways of using > side/in-band channels to send volume control information to the > decoder. It's going to be protocol-specific. So maybe we need to > provide the client with an information coming from the sink on whether > volume control is actually supported or not. Tanu's independently working on flags and notifications for signalling when a sink-input (and sink, I believe) volume control is readable/writeable. We're aiming to have this in 1.0 as well, so we should end up piggybacking on his work for passthrough streams/sinks as well. -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [WIP] Passthrough support
On Tue, 2011-03-15 at 23:13 -0600, Kelly Anderson wrote: > On 03/15/11 22:04, Arun Raghavan wrote: > > On Tue, 2011-03-15 at 18:50 -0600, Kelly Anderson wrote: > >> On 03/09/11 03:10, Arun Raghavan wrote: > >>> Hello all, > >>> Based on the RFC I posted earlier, I've implemented basic passthrough > >>> support in some usable shape. It's up on the passthrough branch of each > >>> of: > >>> > >>> PulseAudio: > >>> http://git.collabora.co.uk/?p=user/arun/pulseaudio.git;a=shortlog;h=refs/heads/passthrough > >>> gst-plugins-base: > >>> http://git.collabora.co.uk/?p=user/arun/gst-plugins-base.git;a=shortlog;h=refs/heads/passthrough > >>> gst-plugins-good: > >>> http://git.collabora.co.uk/?p=user/arun/gst-plugins-good.git;a=shortlog;h=refs/heads/passthrough > >>> > >> > > Hey Arun, > > I've built and installed the passthrough branch. Great! Thanks for testing this out. :) > Isn't changing sample rates supported yet? So far I can only > passthrough sample rates that match the default-sample-rate in > daemon.conf. Changeable rates is critical to being able to support for > example dts-hd at 192khz, when standard dts will be 48khz. > > I'm using paplay for basic functionality checks. It will work, but not with paplay, only with the extended API when you create a non-PCM stream. I will rationalise the check for passthrough sink inputs in a bit, but for now, could you change the checks (there are 2) in alsa-sink sink_process_msg() from: if (PA_LIKELY(pa_format_info_is_pcm(i->format))) to: if (PA_LIKELY(!(i->flags & PA_SINK_INPUT_PASSTHROUGH))) This should make the sample-rate reconfiguration work for paplay as well. I'll apply your HDMI-related patch and push it to my tree (we should really be probing - I'll look into this once the other bits are done). Cheers, Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [WIP] Passthrough support
On Tue, 2011-03-15 at 18:50 -0600, Kelly Anderson wrote:
> On 03/09/11 03:10, Arun Raghavan wrote:
> > Hello all,
> > Based on the RFC I posted earlier, I've implemented basic passthrough
> > support in some usable shape. It's up on the passthrough branch of each
> > of:
> >
> > PulseAudio:
> > http://git.collabora.co.uk/?p=user/arun/pulseaudio.git;a=shortlog;h=refs/heads/passthrough
> > gst-plugins-base:
> > http://git.collabora.co.uk/?p=user/arun/gst-plugins-base.git;a=shortlog;h=refs/heads/passthrough
> > gst-plugins-good:
> > http://git.collabora.co.uk/?p=user/arun/gst-plugins-good.git;a=shortlog;h=refs/heads/passthrough
> >
>
> Hello,
>
> I'm wanting to clone the passthrough head but I haven't been able to
> figure out which git option I need. So far All I've been able to get is
> master.
>
> git ls-remote git://git.collabora.co.uk/git/user/arun/pulseaudio.git
After the clone, you need to do a:
git checkout -b passthrough origin/passthrough
This will create ans switch to a branch called "passthrough" which will
track the remote branch "passthrough" from the tree you cloned
("origin").
You can switch to other branches after this with:
git checkout
Cheers,
Arun
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [WIP] Passthrough support
On Tue, 2011-03-15 at 01:36 +0530, Arun Raghavan wrote: > On Mon, 2011-03-14 at 14:57 -0500, pl bossart wrote: > > >> Other things I noticed: the volume is much higher in passthrough mode, > > >> maybe we need to find a way to set the volume on the headset to match > > >> the volume used for PCM. Also I heard some high-frequency modulations, > > >> typically coding noise, maybe there's still something fishy during the > > >> mp3 decode part. > > > > > > I get this sort of thing on, as far as I can tell, one channel as well. > > > I figured the decoder on the CSR chip wasn't that great. > > > > Looks to me that the quality is slightly worse than with the initial > > patches, but it's of course a very subjective assessment since I need > > to reinstall pulse/gstreamer to check the differences instead of doing > > an A/B test. Can you check and make sure the payloader doesn't > > skip/change any bytes? If you dump what is actually sent to the > > headset and compare to the initial file, you shouldn't have any > > deltas. > > Yep, I did that before I pushed out the code (verified a few frames by > hand, but I'll do something more extensive in the morning). I'm still > seeing the setconf error, but now that it's at least clear it's > connecting to the wrong seid, I'm hoping to get this fixed. Turns out this was very likely a bluez problem. I've sent in a patch [1] that at least gets things working for me. I also see the high-pitched pops and clicks (these very definitely weren't there with your payloader) - should get that pinned down before long. I pushed your change along with a fix for the assert you saw to my tree as well. Cheers, Arun [1] http://thread.gmane.org/gmane.linux.bluez.kernel/11715 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [WIP] Passthrough support
On Mon, 2011-03-14 at 14:57 -0500, pl bossart wrote: > >> Other things I noticed: the volume is much higher in passthrough mode, > >> maybe we need to find a way to set the volume on the headset to match > >> the volume used for PCM. Also I heard some high-frequency modulations, > >> typically coding noise, maybe there's still something fishy during the > >> mp3 decode part. > > > > I get this sort of thing on, as far as I can tell, one channel as well. > > I figured the decoder on the CSR chip wasn't that great. > > Looks to me that the quality is slightly worse than with the initial > patches, but it's of course a very subjective assessment since I need > to reinstall pulse/gstreamer to check the differences instead of doing > an A/B test. Can you check and make sure the payloader doesn't > skip/change any bytes? If you dump what is actually sent to the > headset and compare to the initial file, you shouldn't have any > deltas. Yep, I did that before I pushed out the code (verified a few frames by hand, but I'll do something more extensive in the morning). I'm still seeing the setconf error, but now that it's at least clear it's connecting to the wrong seid, I'm hoping to get this fixed. -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [WIP] Passthrough support
On Mon, 2011-03-14 at 13:43 -0500, pl bossart wrote: > > I forced support for pulse1.0 it by hand in config.h and found the > > same problem with the headset. Trying to figure out the differences > > with my initial patches. there must be a step missing. > > ok, found a solution, see diff attached. For some reason the > setup_ad2p() did both the SBC and MPEG configuration. Adding a test > for the mode solves the issue, probably there was a buffer overflow or > something bad. Thanks! I was getting around to this view as well - the set_configuration seems to be failing because we're trying to set MPEG caps on the SBC seid. > playing with SBC and MPEG works fine now, meaning that the negotiation > works well depending on the payload. > but when I try to go back to PCM/SBC the second time I get the > following assert in pulseaudio (see gst log below) > E: module-bluetooth-device.c: Assertion 'u->write_memchunk.length == > u->block_size' failed at > modules/bluetooth/module-bluetooth-device.c:1519, function > a2dp_process_render(). Aborting. > > I'll let you debug this one, should be easier :-) :) ack. > Other things I noticed: the volume is much higher in passthrough mode, > maybe we need to find a way to set the volume on the headset to match > the volume used for PCM. Also I heard some high-frequency modulations, > typically coding noise, maybe there's still something fishy during the > mp3 decode part. I get this sort of thing on, as far as I can tell, one channel as well. I figured the decoder on the CSR chip wasn't that great. Cheers, Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [WIP] Passthrough support
On Mon, 2011-03-14 at 11:06 -0500, pl bossart wrote: > > I've pushed updates to passthrough-bt branches on my trees for > > pulseaudio (some core changes, rebased to current master), > > gst-plugins-base (MPEG audio payloader), and gst-plugins-good (pulsesink > > MPEG support). With all this, you should be able to test on your BT > > headset. > > I've got all these hanges, but still no luck. > > [ume@plb GST]$ gst-launch filesrc > location=~/AURAL/Audio/theTest-320.mp3 ! pulsesink > device=bluez_sink.00_0B_E4_94_31_9D > Setting pipeline to PAUSED ... > Pipeline is PREROLLING ... > ERROR: from element /GstPipeline:pipeline0/GstPulseSink:pulsesink0: > The stream is in the wrong format. > Additional debug info: > gstbaseaudiosink.c(914): gst_base_audio_sink_preroll (): > /GstPipeline:pipeline0/GstPulseSink:pulsesink0: > sink not negotiated. > ERROR: pipeline doesn't want to preroll. > Setting pipeline to NULL ... > Freeing pipeline ... > [ume@plb GST]$ gst-launch filesrc > location=~/AURAL/Audio/theTest-320.mp3 ! mp3parse ! pulsesink > device=bluez_sink.00_0B_E4_94_31_9D > 0:00:00.022098216 30380 0x8add070 ERROR GST_PIPELINE > ../grammar.y:614:gst_parse_perform_link: could not link mpegaudioparse0 > to pulsesink0 > WARNING: erroneous pipeline: could not link mpegaudioparse0 to pulsesink0 > > what I am missing in the setup ? PCM playback seems to work fine. There was one bit from pulsesink in gst-plugins-good that I'd missed pushing till a couple of hours ago which actually enables MP3 support on the pulsesink side. I'm guessing that is missing in your tree? If not, running gst-launch with --gst-debug=baseaudiosink:5,pulse*:5 should produce some more verbose logs that I can look at. Cheers, Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [WIP] Passthrough support
On Sun, 2011-03-13 at 09:01 +0530, Arun Raghavan wrote: [...] > That would be great - I should have the payloader done and pushed > tomorrow. I've pushed updates to passthrough-bt branches on my trees for pulseaudio (some core changes, rebased to current master), gst-plugins-base (MPEG audio payloader), and gst-plugins-good (pulsesink MPEG support). With all this, you should be able to test on your BT headset. FWIW, my headset dies at SET_CONFIGURATION time, rejecting the configuration that gets pushed to it. Cheers, Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [WIP] Passthrough support
On Sat, 2011-03-12 at 16:01 -0600, pl bossart wrote: > Looked at the BT modifications, doesn't look too bad. > I would try first with MP3 support only, so that you don't have > reconfiguration issues. If you support MP3 only from the beginning, it > should be easier to make progress. Yep, I did that locally. No luck, unfortunately. > If you can work on integrating the payloader in gstaudioiec61937 I > will be able to help you then. That would be great - I should have the payloader done and pushed tomorrow. -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [WIP] Passthrough support
On Sat, 2011-03-12 at 15:08 -0600, pl bossart wrote:
> Hi Arun,
> I looked at the passthrough branch. Looks pretty good. I wrote down some
> notes:
>
> gstaudioiec61937:
> - need to check that frame is valid and synchronized on AC3 header
> before pushing iec payload
I'm expecting valid data from the parser - don't think it makes sense to
duplicate the code from the parser. Now that you mention it though, I'm
only using "framed=true" for the incoming caps, and this might not
actually force the parser to be plugged. Will look into this.
> - no code for mp3 and dts?
DTS is present now. MP3 should be there tomorrow.
> pulsesink:
> - do we really need two steps for payload and commit? Make
> things complicated and creates memory copies
As the comment there says, we can avoid the duplicate copy by doing the
alloc in the payloader. The base class for pulsesink works at sample
granularity (and not byte granularity), so it became necessary to do the
payloading near the beginning of the base class render function.
> - commit needs to prevent toy resampler (maybe this means the sink
> cannot work iwth a live source since no adjustment is possible.
Must've dropped your check somehow. Will put it back.
> - spec.latency_time = GST_BASE_AUDIO_SINK (psink)->latency_time;
> if (!gst_ring_buffer_parse_caps (&spec, caps))
> goto out;
>
> Does this work? spec is not initialized?
Yes, _parse_caps() fills the spec.
> - change of routing?
Working on this.
> - formats
> /* FIXME: Eventually, we want the list of supported formats to be set
> + * as properties by the GUI based on what the user says is supported
> by
> + * the receiver */
> +/* FIXME: How do we figure out supported rates? :( */
> +unsigned int i, rates[] = { 32000, 44100, 48000 };
>
> For HDMI and SPDIF, 32,44.1 and 48 are mandatory. I think you can
> query the alsa layer
> to give a range of supported frequencies since this is known in
> the driver (either hard-coded or obtained with EDID/eld). I remember
> seeing some ALSA patches on this for the NVIDIA cards.
Great, I'll look this up.
> sink.c
> - how do we notify client that volume is disabled?
Tanu's started some work to make this possible. Will coordinate with him
and reuse the work already being done there.
> I wasn't too clear on the BT support. You mentioned that it was a
> different branch and that it stilll nneds my patches to gst-ugly. We'd
> need to have the payloader code in gsraudioiec61937 instead? I am also
> not sure how we handle the transition from A2DP w/ SBC to A2DP w/ MP3.
> In the current code for iec958, there's no need to reconfigure the
> link.
>
> Last, I had 3 conflicts with git master that I had to solve by hand.
That's odd. I'll do a rebase and push tomorrow.
Thanks for the review!
Arun
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] What tests on AMD and ARM are needed for Orc-based optimised volume scaling?
Hi Paul, On Thu, 2011-03-10 at 13:02 +0100, Paul Menzel wrote: > Dear Arun, > > > your commit messages of commit 4cd90d9e [1] says the following. > > … Since I haven't been able to test on other architectures, the > Orc code is only used when MMX/SSE* is present. This can be > changed in the future after testing on AMD and ARM machines. > > What tests need to be performed or what tests did you run to figure out > that it works. Sorry, I should've cleaned up that comment. By AMD, I meant CPUs with 3DNow! but no SSE/MMX support. I don't actually see the 3DNOW flags used at any point other than detection, so there shouldn't be anything to worry about here. On ARM, I actually did a quick test and the Orc performance was significantly worse [1]. I don't think I tested the NEON backend, though. The test is simple - I #define RUN_TEST in each of the svolume_* files that I want to check, bump up the number of iterations to 1 or more, and then load pulseaudio a few times to get a fair measurement (the test generates N random samples and runs the scaling function on them). If you want to try this, you'll also need to adjust the conditional orc initialisation in src/pulsecore/cpu-orc.c. Cheers, Arun [1] The hand-rolled ARM code is faster than the Orc ARM backend because the former uses a single instruction that is available on ARM to do what the Orc function does using multiple instructions. I'd spoken to Orc upstream (David Schleef) about the possibility of having this scaling operation as a basic Orc operation, so that we could generate that instruction on ARM and fallback to the multiple instructions on other architectures. He was amenable to the idea, but I haven't had time to actually hack this together. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [WIP] Passthrough support
On Wed, 2011-03-09 at 15:40 +0530, Arun Raghavan wrote: > Hello all, > Based on the RFC I posted earlier, I've implemented basic passthrough > support in some usable shape. It's up on the passthrough branch of each > of: > > PulseAudio: > http://git.collabora.co.uk/?p=user/arun/pulseaudio.git;a=shortlog;h=refs/heads/passthrough > gst-plugins-base: > http://git.collabora.co.uk/?p=user/arun/gst-plugins-base.git;a=shortlog;h=refs/heads/passthrough > gst-plugins-good: > http://git.collabora.co.uk/?p=user/arun/gst-plugins-good.git;a=shortlog;h=refs/heads/passthrough > > What's here? All the basic plumbing for clients to signal a compresed > format, have PA pick the "best" supported one, actually play that > format, and have pactl list show these. The ALSA sink takes AC3 at the > moment, and I should be pushing DTS support today/tomorrow after some > more testing. FWIW, this has now been pushed too. Needed some changes to the DTS parser in GStreamer, which can be found at: http://git.collabora.co.uk/?p=user/arun/gst-plugins-bad.git;a=shortlog;h=refs/heads/passthrough -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [WIP] Passthrough support
Hello all, Based on the RFC I posted earlier, I've implemented basic passthrough support in some usable shape. It's up on the passthrough branch of each of: PulseAudio: http://git.collabora.co.uk/?p=user/arun/pulseaudio.git;a=shortlog;h=refs/heads/passthrough gst-plugins-base: http://git.collabora.co.uk/?p=user/arun/gst-plugins-base.git;a=shortlog;h=refs/heads/passthrough gst-plugins-good: http://git.collabora.co.uk/?p=user/arun/gst-plugins-good.git;a=shortlog;h=refs/heads/passthrough What's here? All the basic plumbing for clients to signal a compresed format, have PA pick the "best" supported one, actually play that format, and have pactl list show these. The ALSA sink takes AC3 at the moment, and I should be pushing DTS support today/tomorrow after some more testing. It was a lot simpler for me to test this with pulsesink, so I've made the required changes there (I realise this is a bother for those who don't have local builds of gstreamer handy - sorry!). Eventually, I'd like to have a paplay-type interface for compressed formats (pre-payloaded). What's left? * Triggering renegotiation - I should be getting to this soon * Better proplists - We have one proplist per format+rate pair, which is fine for now, but eventually, we need to freeze the string format for lists/ranges * Proper UI for selecting accepted formats - I'm thinking that we need to add bits to the various UIs to provide a checklist of formats that the user's receiver accepts, set that as a property on the sink, and have a module save this (m-d-m, perhaps, or just a new module) * HDMI - in theory this should be easy to support, but I've not tested this yet * Bluetooth - See postscript * Sink-input passthrough flag to go away - I'll do this after paplay properly supports compressed formats * Disabling monitors - I suspend them for now, which seems to work okay, but we probably want to have way to disable these properly * Disabling volume - I'm planning on piggybacking on Tanu's work here :) So that's that. Comments and feedback appreciated. :) Cheers, Arun p.s.: BT support is being a major pita, mostly because my headset refuses to cooperate. There's a passthrough-bt branch in my PA tree which adapts the a2dp sink to the new API, and Pierre's patch for an IEC61937 payloader that never made it to the mailing list is at http://people.collabora.co.uk/~arun/plbossart-gst-plugins-ugly.patch (just needs a small change to pulseutil.c to set make the appropriate gst->pa type translation). ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 1/2] Log feature:Add a new log target to a file descriptor
Hi,
I haven't tested your patch, but some comments on the code below.
On Tue, 2011-03-08 at 17:15 +0100, Vincent Becker wrote:
> This patch enables logging of text debug messages (pa_log feature) into a
> file or a device driver.
> Example : pulseaudio --log-target=file:./mylog.txt
>
> Signed-off-by: Vincent Becker
> ---
> src/daemon/cmdline.c |5 +++--
> src/daemon/daemon-conf.c | 34 --
> src/pulsecore/log.c | 24
> src/pulsecore/log.h |5 +
> 4 files changed, 64 insertions(+), 4 deletions(-)
>
> diff --git a/src/daemon/cmdline.c b/src/daemon/cmdline.c
> index f6cdcdc..2c3eb67 100644
> --- a/src/daemon/cmdline.c
> +++ b/src/daemon/cmdline.c
> @@ -145,7 +145,8 @@ void pa_cmdline_help(const char *argv0) {
> "this time passed\n"
> " --log-level[=LEVEL] Increase or set
> verbosity level\n"
> " -vIncrease the verbosity
> level\n"
> - " --log-target={auto,syslog,stderr} Specify the log target\n"
> + " --log-target={auto,syslog,stderr,\n"
> + "file:PATH} Specify the log target\n"
> " --log-meta[=BOOL] Include code location in
> log messages\n"
> " --log-time[=BOOL] Include timestamps in
> log messages\n"
> " --log-backtrace=FRAMESInclude a backtrace in
> log messages\n"
> @@ -318,7 +319,7 @@ int pa_cmdline_parse(pa_daemon_conf *conf, int argc, char
> *const argv [], int *d
>
> case ARG_LOG_TARGET:
> if (pa_daemon_conf_set_log_target(conf, optarg) < 0) {
> -pa_log(_("Invalid log target: use either 'syslog',
> 'stderr' or 'auto'."));
> +pa_log(_("Invalid log target: use either 'syslog',
> 'stderr', 'auto' or a valid file name 'file:'."));
> goto fail;
> }
> break;
> diff --git a/src/daemon/daemon-conf.c b/src/daemon/daemon-conf.c
> index e38e67a..5696f00 100644
> --- a/src/daemon/daemon-conf.c
> +++ b/src/daemon/daemon-conf.c
> @@ -28,6 +28,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #ifdef HAVE_SCHED_H
> #include
> @@ -141,6 +143,9 @@ static const pa_daemon_conf default_conf = {
> #endif
> };
>
> +static int log_fd = -1;
> +
> +
> pa_daemon_conf* pa_daemon_conf_new(void) {
> pa_daemon_conf *c;
>
> @@ -166,6 +171,9 @@ pa_daemon_conf* pa_daemon_conf_new(void) {
>
> void pa_daemon_conf_free(pa_daemon_conf *c) {
> pa_assert(c);
> +if (log_fd >= 0)
> +pa_close(log_fd);
> +
> pa_xfree(c->script_commands);
> pa_xfree(c->dl_search_path);
> pa_xfree(c->default_script_file);
> @@ -185,8 +193,30 @@ int pa_daemon_conf_set_log_target(pa_daemon_conf *c,
> const char *string) {
> } else if (!strcmp(string, "stderr")) {
> c->auto_log_target = 0;
> c->log_target = PA_LOG_STDERR;
> -} else
> -return -1;
> +} else if (pa_startswith(string, "file:")) {
> +char *file_path;
> +const char *state = NULL;
> +unsigned i;
> +
> +/* After second pa_split call, file_path will contain the right part
> of file: */
> +for (i = 0; i < 2; i++)
> +file_path = pa_split(string, ":", &state);
I believe this would leak. You could just use file_path = &string[5]
here.
> +/* Check if the file is regular */
> +if ((log_fd = open(file_path, O_RDWR|O_TRUNC|O_CREAT, 0777)) >= 0) {
Definitely don't want to give execute permissions for that file. For
paranoia's sake, I'd use S_IRWXU.
> +c->auto_log_target = 0;
> +c->log_target = PA_LOG_FD;
> +pa_log_set_fd(log_fd);
> +}
> +else {
> +printf("Failed to open target file %s, error : %s\n", file_path,
> pa_cstrerror(errno));
> +pa_xfree(file_path);
> +return -1;
> +}
> +pa_xfree(file_path);
> +}
> +else
> + return -1;
>
> return 0;
> }
> diff --git a/src/pulsecore/log.c b/src/pulsecore/log.c
> index 2c0e267..a5e26c8 100644
> --- a/src/pulsecore/log.c
> +++ b/src/pulsecore/log.c
> @@ -71,6 +71,8 @@ static unsigned show_backtrace = 0, show_backtrace_override
> = 0, skip_backtrace
> static pa_log_flags_t flags = 0, flags_override = 0;
> static pa_bool_t no_rate_limit = FALSE;
>
> +static int fdlog = -1;
> +
> #ifdef HAVE_SYSLOG_H
> static const int level_to_syslog[] = {
> [PA_LOG_ERROR] = LOG_ERR,
> @@ -128,6 +130,12 @@ void pa_log_set_flags(pa_log_flags_t _flags,
> pa_log_merge_t merge) {
> flags = _flags;
> }
>
> +void pa_log_set_fd(int fd) {
> +pa_assert(fd >= 0);
> +
> +fdlog = fd;
> +}
> +
> void pa_log_set_show_backtrace(unsigned nlevels) {
>
Re: [pulseaudio-discuss] [PATCH 0/5] Reconfigure sample rates on resume
On Tue, 2011-03-08 at 07:03 -0600, pl bossart wrote: > > At sink-input trigger a reconfiguration if possible/supported. Sinks > > expose a reconfigure_rate method (I'm sure we can find a better name) if > > they can do a quick switch. > > So far it's similar to the update_rate() method I added on the sink, > > In the ALSA sink, this function would check if there are no sink-inputs > > attached and the rate is supported, and then send a message to the I/O > > thread to do the actual reconfiguration. We would cache the rate if > > suspended and apply on unsuspend, or do a suspend-reconfigure-unsuspend > > if it's running. > > It's interesting. > The only problems I see is a potential duplication of code, since you > force the suspend in the sink, and it's already part of > module-suspend-on-idle. Meaning you will need to implement this > message in the BT sink as well. I wonder if there would be potential I assumed we'd only be implementing this in ALSA for now since we're not allowing reconfiguration on BT in your patches either. Either way, I don't expect there to be too much duplication. > races if the suspend-on-idle timeout happens right after you enable > the new stream. This should get serialised in the mainloop as far as I can tell. > > With this, we can replace default-sample-rate with a minimum-sample-rate > > (anything below this gets upsampled), and use the sink-input sample rate > > if supported (or an integer multiple as your code does). The advantage > > of course is that we're no longer restricted to two sample rates. > > I don't really see a benefit of having more than 2 sample rates. The > only exception is > passthrough, where you want to forward the sink-input frequency as is. > And reading again I think it's the same behavior I implemented? The benefit is just that if you have ultra-high-quality 88.4/96 kHz music, it doesn't get resampled. I honestly don't know how many people out there care about this, but if the hardware supports higher sample rates, I see no reason to not expose the ability to play that. > > I did a quick walk over the code and this seems feasible. I'm doing > > something similar (but far simpler) for passthrough mode in alsa-sink - > > when a passthrough input is added, I do the > > suspend-update_rate-unsuspend if required and it seems to work fine. > > > > Does this make sense or am I missing something basic here? > > Couldn't you add the same behavior with my patches? If the sink-input > is passthrough then the desired rate is the sink-input rate. > Overall I am still not clear on what your alternative implementation > brings? But I am badly jet-lagged, I may have missed something as > well. Yes, whatever the final solution is, I'll definitely be reusing this API in my passthrough work. Cheers, Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 0/5] Reconfigure sample rates on resume
On Sun, 2011-03-06 at 16:30 -0600, Pierre-Louis Bossart wrote: > This is the second version of my endeavors to remove or make SRC > simpler when possible. An idle non-network, local or passthrough > devices will be suspended immediately when there aren't any > inputs. When a new input is connected, we try to resume with the best match > between requested sample rate and sink sample rate. To make things > simple, the sink can only support a default and an alternate rate, > typically 44.1 and 48kHz. Of course the feature is disabled when both > rates are identical (if the sink cannot be reconfigured). Tests with > HDAudio and USB show a negligible added delay but a nice reduction of > CPU activity. An alternative idea: At sink-input trigger a reconfiguration if possible/supported. Sinks expose a reconfigure_rate method (I'm sure we can find a better name) if they can do a quick switch. In the ALSA sink, this function would check if there are no sink-inputs attached and the rate is supported, and then send a message to the I/O thread to do the actual reconfiguration. We would cache the rate if suspended and apply on unsuspend, or do a suspend-reconfigure-unsuspend if it's running. With this, we can replace default-sample-rate with a minimum-sample-rate (anything below this gets upsampled), and use the sink-input sample rate if supported (or an integer multiple as your code does). The advantage of course is that we're no longer restricted to two sample rates. I did a quick walk over the code and this seems feasible. I'm doing something similar (but far simpler) for passthrough mode in alsa-sink - when a passthrough input is added, I do the suspend-update_rate-unsuspend if required and it seems to work fine. Does this make sense or am I missing something basic here? Cheers, Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Nvidia hdmi passthrough
On Fri, 2011-03-04 at 20:47 -0700, Kelly Anderson wrote: > diff --git a/src/Makefile.am b/src/Makefile.am > index 24e2f82..bb501fb 100644 > --- a/src/Makefile.am > +++ b/src/Makefile.am > @@ -1131,7 +1131,9 @@ dist_alsapaths_DATA = \ > modules/alsa/mixer/paths/analog-output-lfe-on-mono.conf \ > modules/alsa/mixer/paths/analog-output-mono.conf \ > modules/alsa/mixer/paths/iec958-stereo-output.conf \ > - modules/alsa/mixer/paths/iec958-passthrough-output.conf > + modules/alsa/mixer/paths/iec958-passthrough-output.conf \ > + modules/alsa/mixer/paths/hdmi-stereo-output.conf \ > + modules/alsa/mixer/paths/hdmi-passthrough-output.conf The additional passthrough profile will become moot once my branch is ready to merge. Please hold off merging this for now. I should have something for you to rebase on before long. -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] introspect: Client-side implementation for has_volume/read_only_volume
On Tue, 2011-03-01 at 21:38 +0200, Tanu Kaskinen wrote:
> On Wed, 2011-03-02 at 00:43 +0530, Arun Raghavan wrote:
> > This completes the client-side changes to the protocol extension
>
> Thanks for fixing this!
>
> I forgot also incrementing PA_PROTOCOL_VERSION in my patch, so you
> should fix that too.
Missed that because of my local changes.
> > introduced by commit 99ddca89cdca9b0b92ab9870764f9211e6a82e31
> > ---
> > src/pulse/introspect.c |8 ++--
> > 1 files changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/src/pulse/introspect.c b/src/pulse/introspect.c
> > index 2a81788..575ca8d 100644
> > --- a/src/pulse/introspect.c
> > +++ b/src/pulse/introspect.c
> > @@ -996,7 +996,7 @@ static void
> > context_get_sink_input_info_callback(pa_pdispatch *pd, uint32_t comm
> >
> > while (!pa_tagstruct_eof(t)) {
> > pa_sink_input_info i;
> > -pa_bool_t mute = FALSE, corked = FALSE;
> > +pa_bool_t mute = FALSE, corked = FALSE, has_volume,
> > read_only_volume;
>
> The new variables should be initialized - if the server uses a protocol
> version less than 20, you assign undefined values to i.has_volume and
> i.read_only_volume.
D'oh! Agreed and sent fixed patch.
-- Arun
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH] introspect: Client-side implementation for has_volume/read_only_volume
This completes the client-side changes to the protocol extension
introduced by commit 99ddca89cdca9b0b92ab9870764f9211e6a82e31
---
configure.ac |2 +-
src/pulse/introspect.c |8 ++--
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/configure.ac b/configure.ac
index 21dae30..2171089 100644
--- a/configure.ac
+++ b/configure.ac
@@ -37,7 +37,7 @@ AC_SUBST(PA_MAJORMINOR, pa_major.pa_minor)
AC_SUBST(PACKAGE_URL, [http://pulseaudio.org/])
AC_SUBST(PA_API_VERSION, 12)
-AC_SUBST(PA_PROTOCOL_VERSION, 19)
+AC_SUBST(PA_PROTOCOL_VERSION, 20)
# The stable ABI for client applications, for the version info x:y:z
# always will hold y=z
diff --git a/src/pulse/introspect.c b/src/pulse/introspect.c
index 2a81788..35e091a 100644
--- a/src/pulse/introspect.c
+++ b/src/pulse/introspect.c
@@ -996,7 +996,7 @@ static void
context_get_sink_input_info_callback(pa_pdispatch *pd, uint32_t comm
while (!pa_tagstruct_eof(t)) {
pa_sink_input_info i;
-pa_bool_t mute = FALSE, corked = FALSE;
+pa_bool_t mute = FALSE, corked = FALSE, has_volume = FALSE,
read_only_volume = FALSE;
pa_zero(i);
i.proplist = pa_proplist_new();
@@ -1015,7 +1015,9 @@ static void
context_get_sink_input_info_callback(pa_pdispatch *pd, uint32_t comm
pa_tagstruct_gets(t, &i.driver) < 0 ||
(o->context->version >= 11 && pa_tagstruct_get_boolean(t,
&mute) < 0) ||
(o->context->version >= 13 && pa_tagstruct_get_proplist(t,
i.proplist) < 0) ||
-(o->context->version >= 19 && pa_tagstruct_get_boolean(t,
&corked) < 0)) {
+(o->context->version >= 19 && pa_tagstruct_get_boolean(t,
&corked) < 0) ||
+(o->context->version >= 20 && (pa_tagstruct_get_boolean(t,
&has_volume) < 0 ||
+ pa_tagstruct_get_boolean(t,
&read_only_volume) < 0))) {
pa_context_fail(o->context, PA_ERR_PROTOCOL);
pa_proplist_free(i.proplist);
@@ -1024,6 +1026,8 @@ static void
context_get_sink_input_info_callback(pa_pdispatch *pd, uint32_t comm
i.mute = (int) mute;
i.corked = (int) corked;
+i.has_volume = (int) has_volume;
+i.read_only_volume = (int) read_only_volume;
if (o->callback) {
pa_sink_input_info_cb_t cb = (pa_sink_input_info_cb_t)
o->callback;
--
1.7.4.1
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH] introspect: Client-side implementation for has_volume/read_only_volume
This completes the client-side changes to the protocol extension
introduced by commit 99ddca89cdca9b0b92ab9870764f9211e6a82e31
---
src/pulse/introspect.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/pulse/introspect.c b/src/pulse/introspect.c
index 2a81788..575ca8d 100644
--- a/src/pulse/introspect.c
+++ b/src/pulse/introspect.c
@@ -996,7 +996,7 @@ static void
context_get_sink_input_info_callback(pa_pdispatch *pd, uint32_t comm
while (!pa_tagstruct_eof(t)) {
pa_sink_input_info i;
-pa_bool_t mute = FALSE, corked = FALSE;
+pa_bool_t mute = FALSE, corked = FALSE, has_volume,
read_only_volume;
pa_zero(i);
i.proplist = pa_proplist_new();
@@ -1015,7 +1015,9 @@ static void
context_get_sink_input_info_callback(pa_pdispatch *pd, uint32_t comm
pa_tagstruct_gets(t, &i.driver) < 0 ||
(o->context->version >= 11 && pa_tagstruct_get_boolean(t,
&mute) < 0) ||
(o->context->version >= 13 && pa_tagstruct_get_proplist(t,
i.proplist) < 0) ||
-(o->context->version >= 19 && pa_tagstruct_get_boolean(t,
&corked) < 0)) {
+(o->context->version >= 19 && pa_tagstruct_get_boolean(t,
&corked) < 0) ||
+(o->context->version >= 20 && (pa_tagstruct_get_boolean(t,
&has_volume) < 0 ||
+ pa_tagstruct_get_boolean(t,
&read_only_volume) < 0))) {
pa_context_fail(o->context, PA_ERR_PROTOCOL);
pa_proplist_free(i.proplist);
@@ -1024,6 +1026,8 @@ static void
context_get_sink_input_info_callback(pa_pdispatch *pd, uint32_t comm
i.mute = (int) mute;
i.corked = (int) corked;
+i.has_volume = (int) has_volume;
+i.read_only_volume = (int) read_only_volume;
if (o->callback) {
pa_sink_input_info_cb_t cb = (pa_sink_input_info_cb_t)
o->callback;
--
1.7.4.1
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH] introspect: Client-side implementation for has_volume/read_only_volume
I got bitten by this (stream aborts because client iterates on the introspection data till all data is consumed), so hacked up a quick patch in case Tanu hasn't had the time to get to this yet. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
On Sun, 2011-02-27 at 23:20 -0800, Christ Schlacta wrote: [...] > mark settings as optional or required for negotiation. if one or the > other can't support an "Optional" parameter, then it gets replied to as > unsupported but continuing. a warning is logged. a mandatory option > will cause it to fail with an error message logged (Warning, Remote sink > doesn't support required option "bitrate". either upgrade Remote Sink, > or set bitrate as optional by using "optional bitrate foo") or similar. We can do this, but what does it really get us? On the sink side, we know what restrictions we want to place on the input, and it's reasonable to assume anything unspecified is fine (if it's not, it should be specified as a restriction anyway). On the stream side, we're not providing the information as a restriction - we're saying "I have this stream, it can be with one of these formats/properties, find me a sink to plug into". What would an optional parameter achieve here? -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [Patch] Infinite loop in mainloop
Hi Marcel, On Sat, 2011-01-01 at 16:50 +0100, Marcel wrote: > I am porting pulseaudio to OS/2. During this I run into trouble with the > mainloop occasionally eating up all CPU resources. It turned out to be > an inconsistency in the internal state of the mainloop. > m->wakeup_requested was 0 while the wakup pipe was ready. In fact most > probably there is still a race condition somewhere in the code. > > However, the following patch will help to recover from this > inconsistencies more gracefully, especially if the mainloop is running > at high priority. This came up in the meeting last Thursday [1]. Could you provide more context on this? It does appear that this is some sort of OS/2 bug rather than a bug in PA. If no other information is available, then I think this is okay to go in with an OS/2-specific conditional. Cheers, Arun [1] http://colin.guthr.ie/meetings/pulseaudio-meeting/2011/pulseaudio-meeting.2011-02-24-21.02.log.html#l-379 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
On Tue, 2011-02-22 at 22:52 +0200, Tanu Kaskinen wrote: [...] > The set of parameters can potentially grow forever - we don't know what > parameters may become relevant in the future. So, I think we should > start by documenting the parameters that we know are important today, > and define the approach for adding new parameters in the future. > > When thinking about handling unknown parameters, there are four cases > that need to be considered: > > 1) A sink has a parameter that a client doesn't understand. > 2) A source has a parameter that a client doesn't understand. > 3) A playback stream has a parameter that a server doesn't understand. > 4) A record stream has a parameter that a server doesn't understand. > > The cases 2 and 3 should be easy - if the receiver of the data doesn't > understand a parameter, it means that it doesn't care. The unknown > parameter can be just ignored by the negotiation logic, and the final > format should have that parameter removed from the proplist. > > Cases 1 and 4 are more difficult. One possibility would be to fail the > negotiation in such case. That would require that the sender always > specifies explicitly all parameters that it knows about, even if it can > support anything (IIRC I suggested earlier that a missing parameter > would mean that everything is supported). > > Another possibility would be to try anyway, and the receiver would then > kill the stream if the actual payload wasn't satisfactory. What should > the negotiation logic do in this case? If the unknown parameter is a > fixed value, the parameter should probably be left in the final format > proplist. What if the unknown parameter is a range or a list? Maybe the > negotiation logic should in this case leave the parameter untouched in > the final format proplist. > > I don't know which approach I like more. The first approach (failing) > would be "cleaner", but the second approach (trying anyway) would work > in more cases. I prefer failing if the pa_stream's properties are not a subset of the properties specified by the sink/source. As Pierre mentions, in the foreseeable we're going to be dealing with a limited number of properties (rate, channels, 2-3 codec parameters), so this approach will work until the requirements change in some fundamental way. Cheers, Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 1/6] Implement the "volume sharing" feature.
On Fri, 2011-02-25 at 18:54 +0100, Marc-André Lureau wrote: [...] > So, although it looks weird, this patch (or it's version on N900) is > fairly safe and solve some real use cases. There is no obvious way to > improve it. If it can help Nokia and other people to get this in > (instead of having to maintain it elsewhere), I would say go for it, > yes! ++ on this solving real-world use-cases - the echo-cancel module clearly benefits from this as well. Cheers, Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] Add src/*-symdef.h to .gitignore.
On Sun, 2011-02-27 at 12:50 +0200, Tanu Kaskinen wrote: > --- > src/.gitignore |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/src/.gitignore b/src/.gitignore > index c93974b..1380e26 100644 > --- a/src/.gitignore > +++ b/src/.gitignore > @@ -66,3 +66,4 @@ voltest > start-pulseaudio-x11 > start-pulseaudio-kde > vector-test > +*-symdef.h Had this on my list for this week - you beat me to it! :) We should remove the corresponding entries from the .gitignore files in module subdirs as well since the files aren't created there any more. -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Properties to suppress save/restore of stream volumes
On Fri, 2011-02-25 at 09:42 +, Colin Guthrie wrote: > 'Twas brillig, and Arun Raghavan at 08/02/11 15:34 did gyre and gimble: > > If there are no objections to this approach, we could expose the fading > > API via a property (set it to trigger a fade) and a signal (for the > > fade-done callback). > > > > For the completion notification, I realised we would just pass the > > callback to the _set_volume_with_ramping() function like the rest of the > > API, so nothing new needs to be done for that it seems. > > > > Now all that remains is to figure out whether this belongs in core or in > > an extension. I think it fits in core (a _with_ramping variant of > > existing core API), but I'm not a religious about it. :) > > Just to revive this thread since our meeting > > Now that we know the ramping stuff will be ripped out for 1.0 release > (by your good self Arun!), I guess we can put this on the back burner > for now? Oh, the irony! :) Yep, this will need to fade (:p) to the background. Pity, since the gst side power optimisation also gets postponed as a result, but hopefully it'll be something we can get back to soon after 1.0 (I'm an optimist! :D). Cheers, Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] sbc_math.h: add explicit check for ARMv6 instructions
Hi Paul,
On Tue, 2011-02-22 at 12:33 +0100, Paul Menzel wrote:
> Am Dienstag, den 22.02.2011, 09:48 + schrieb Colin Guthrie:
> > 'Twas brillig, and Arun Raghavan at 21/02/11 20:31 did gyre and gimble:
> > > On Sun, 2011-02-20 at 19:20 +0100, Paul Menzel wrote:
> > >> Date: Sun, 20 Feb 2011 15:57:55 +0100
> > >>
> > >> Building PulseAudio 051d8213 [1] using OpenEmbedded with distribution
> > >> `minimal-uclibc` for `MACHINE="om-gta01"` having an ARMv4T architecture
> > >> (armv4t-oe-linux-uclibceabi) compilation fails with the following error.
> > > [...]
> > >> {standard input}:4099: Error: selected processor does not support Thumb
> > >> mode `mla r3,r2,r6,r3'
> > >> {standard input}:4114: Error: selected processor does not support Thumb
> > >> mode `mla r3,r2,ip,r3'
> > >> {standard input}:4125: Error: selected processor does not support Thumb
> > >> mode `mla r3,r6,r2,r3'
> > >> make[3]: *** [libbluetooth_sbc_la-sbc.lo] Error 1
> > >>
> > >> Apply the same fix as in [2], which is similar to the patch applied in
> > >> OpenEmbedded since commit 976ab4b5 [3].
> > >>
> > >> [1]
> > >> http://git.0pointer.de/?p=pulseaudio.git;a=commit;h=051d82133f0ae6a57bf66fd200bc8e3591a7d5ca
> > >> [2]
> > >> http://git.0pointer.de/?p=pulseaudio.git;a=commit;h=12b900858ae82d435c100d6eb94cb7bb22fe5e29
> > >> [3]
> > >> http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=976ab4b4587d548c0483a274058c5359cb72bf1b
> > >>
> > >> Signed-off-by: Paul Menzel
> > >> CC: Marcel Holtmann
> > >> ---
> > >> I do not know if these files are just copied from linux-bluetooth
> > >> upstream, so I am adding Marcel to CC anyway because he is mentioned in
> > >> the copyright section.
> > >
> > > It does appear that the files are a copy of the bluez package. If we're
> > > fixing this on the PulseAudio side, I think we should include something
> > > like diff below configure.ac, so that we can actually verify that the
> > > mla instruction is available for the arch being used.
> > >
> > > -- Arun
> > >
> > >
> > > diff --git a/configure.ac b/configure.ac
> > > index 08c947a..77e9823 100644
> > > --- a/configure.ac
> > > +++ b/configure.ac
> > > @@ -257,13 +257,14 @@ case $host in
> > > asm volatile ("ldr r0, %2 \n"
> > > "ldr r2, %3 \n"
> > > "ldr r3, %4 \n"
> > > + "mla r4, r1, r2, r3 \n"
> > > "ssat r1, #8, r0 \n"
> > > "str r1, %0 \n"
> > > "pkhbt r1, r3, r2, LSL #8 \n"
> > > "str r1, %1 \n"
> > > : "=m" (a), "=m" (b)
> > > : "m" (a), "m" (b), "m" (c)
> > > - : "r0", "r1", "r2", "r3", "cc");
> > > + : "r0", "r1", "r2", "r3", "r4", "cc");
> > > return (a == -128 && b == 0xaabb) ? 0 : -1;
> > > ]]),
> > > [pulseaudio_cv_support_armv6=yes],
> >
> > Paul, can you confirm if this avoids the problem for you? If so, then
> > Arun, can you make a proper patch? You can? Awesome, thanks :)
>
> Does not Arun’s patch just improve the check for `HAVE_ARMV6`? My patch
> just adds the check `if defined(HAVE_ARMV6)` to `sbc_math.h`. Without
> that addition all the configure checks are not evaluated at all in
> `sbc_math.h`.
For bits other than bluez, we need ARMv6 or above. For the MLA
instruction that's triggering the error you see, we need a version of
ARMv6 or above that also supports Thumb2 [1].
So your patch is incorrect in that it will fail on (e.g.) ARMv6K. My
patch above, on the other hand, will make PA not use v6 asm on ARMv6K
even if bluez support is disabled, which is also incorrect.
The correct fix for this, imo, is in bluez (there is a new
sbc_primitives_armv6.h that can probably be used at least as a
template). We need to do an sbc-udpate on the PA side anyway, and can
pull this when we do.
Cheers,
Arun
[1]
http://infocenter.arm.com/help/topic/com.arm.doc.qrc0001m/QRC0001_UAL.pdf
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
On Tue, 2011-02-22 at 13:27 -0600, pl bossart wrote: > >> Still, I am not clear about the negociation. the client would need to > >> use pa_stream_new_extended with multiple formats, and then get the > >> actual format with get_format_info. If my understanding is correct, > >> then maybe you would need a list of formats instead of just one? > > > > Oh, indeed! That was the intention, but I guess I missed putting that in > > the wiki. Fixed now. > > ok. Looks good. > One last comment on proplists. If we don't define a set of mandatory > elements, then it's going to be really hard to use this > pa_stream_new_extended() routine. How will the client figure out what > exactly it needs to send for each format? I was thinking that his would basically develop as convention, though the few basic properties (rate, channels) could be documented along with the pa_encoding_t structure. We can document additional properties (for example bitrate, if some sink ever needs it) as being optional but recommended if available. -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
On Tue, 2011-02-22 at 11:43 -0600, pl bossart wrote: > > I assume that the every sink that supports PCM will have one format with > > PA_ENCODING_PCM in its list of supported formats. With the extended API, > > I'd like to treat PCM and compressed formats as being equal as much as > > possible. > > ok, now I get it. I didn't see the PA_ENCODING_PCM on the first line... > > Still, I am not clear about the negociation. the client would need to > use pa_stream_new_extended with multiple formats, and then get the > actual format with get_format_info. If my understanding is correct, > then maybe you would need a list of formats instead of just one? Oh, indeed! That was the intention, but I guess I missed putting that in the wiki. Fixed now. Thanks, Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
On Tue, 2011-02-22 at 10:03 -0600, pl bossart wrote: > Hi Arun, > > >> > I've updated this page with the changes discussed so far (and translated > >> > them into the actual API changes that we need). Please take a look and > >> > let me know if this looks acceptable. > > Couple of comments: > - There is a miss on the pa_format_info. the sampling frequency is > required. The IEC format can be used at various sampling frequencies. > Passing just IEC isn't enough to configure the link with the receiver. > The number of channels could be 2 by default, but we may need to > change this as well for formats like TrueHD or DTS Master. I figured it'd be best to leave everything but the format in the proplist and then let the sink pick out the properties it needs/expects. This allows us to keep the structure generic and lets sinks specify what/how much information they need to be able to decide whether a format is supported or not. > - in case no IEC formats are supported by the sink, what is the > returned value? If this is NULL, meaning there is no support, how do > we fall back to plain PCM? I assume that the every sink that supports PCM will have one format with PA_ENCODING_PCM in its list of supported formats. With the extended API, I'd like to treat PCM and compressed formats as being equal as much as possible. > - in case the routing changes, for example if you plug HDMI or BT, how > do we change the connection? The plan is to have clients disconnect and recreate the stream. We could eventually look at a convenience API to do this. -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] sbc_math.h: add explicit check for ARMv6 instructions
On Tue, 2011-02-22 at 09:48 +, Colin Guthrie wrote:
> 'Twas brillig, and Arun Raghavan at 21/02/11 20:31 did gyre and gimble:
> > On Sun, 2011-02-20 at 19:20 +0100, Paul Menzel wrote:
> >> Date: Sun, 20 Feb 2011 15:57:55 +0100
> >>
> >> Building PulseAudio 051d8213 [1] using OpenEmbedded with distribution
> >> `minimal-uclibc` for `MACHINE="om-gta01"` having an ARMv4T architecture
> >> (armv4t-oe-linux-uclibceabi) compilation fails with the following error.
> > [...]
> >>{standard input}:4099: Error: selected processor does not support Thumb
> >> mode `mla r3,r2,r6,r3'
> >>{standard input}:4114: Error: selected processor does not support Thumb
> >> mode `mla r3,r2,ip,r3'
> >>{standard input}:4125: Error: selected processor does not support Thumb
> >> mode `mla r3,r6,r2,r3'
> >>make[3]: *** [libbluetooth_sbc_la-sbc.lo] Error 1
> >>
> >> Apply the same fix as in [2], which is similar to the patch applied in
> >> OpenEmbedded since commit 976ab4b5 [3].
> >>
> >> [1]
> >> http://git.0pointer.de/?p=pulseaudio.git;a=commit;h=051d82133f0ae6a57bf66fd200bc8e3591a7d5ca
> >> [2]
> >> http://git.0pointer.de/?p=pulseaudio.git;a=commit;h=12b900858ae82d435c100d6eb94cb7bb22fe5e29
> >> [3]
> >> http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=976ab4b4587d548c0483a274058c5359cb72bf1b
> >>
> >> Signed-off-by: Paul Menzel
> >> CC: Marcel Holtmann
> >> ---
> >> I do not know if these files are just copied from linux-bluetooth
> >> upstream, so I am adding Marcel to CC anyway because he is mentioned in
> >> the copyright section.
Looking at src/Makefile.am, it looks like at some point of time, we
pulled bluez files directly from git (the update-sbc rule). Does anyone
know what the plan was with regards to keeping these files up-to-date?
There seem to be a bunch of armv6 updates upstream as well.
[...]
> Paul, can you confirm if this avoids the problem for you? If so, then
> Arun, can you make a proper patch? You can? Awesome, thanks :)
:D Once we've resolved what the situation is with bluez files, I'm happy
to help with this.
Cheers,
Arun
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] sbc_math.h: add explicit check for ARMv6 instructions
On Sun, 2011-02-20 at 19:20 +0100, Paul Menzel wrote:
> Date: Sun, 20 Feb 2011 15:57:55 +0100
>
> Building PulseAudio 051d8213 [1] using OpenEmbedded with distribution
> `minimal-uclibc` for `MACHINE="om-gta01"` having an ARMv4T architecture
> (armv4t-oe-linux-uclibceabi) compilation fails with the following error.
[...]
> {standard input}:4099: Error: selected processor does not support Thumb
> mode `mla r3,r2,r6,r3'
> {standard input}:4114: Error: selected processor does not support Thumb
> mode `mla r3,r2,ip,r3'
> {standard input}:4125: Error: selected processor does not support Thumb
> mode `mla r3,r6,r2,r3'
> make[3]: *** [libbluetooth_sbc_la-sbc.lo] Error 1
>
> Apply the same fix as in [2], which is similar to the patch applied in
> OpenEmbedded since commit 976ab4b5 [3].
>
> [1]
> http://git.0pointer.de/?p=pulseaudio.git;a=commit;h=051d82133f0ae6a57bf66fd200bc8e3591a7d5ca
> [2]
> http://git.0pointer.de/?p=pulseaudio.git;a=commit;h=12b900858ae82d435c100d6eb94cb7bb22fe5e29
> [3]
> http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=976ab4b4587d548c0483a274058c5359cb72bf1b
>
> Signed-off-by: Paul Menzel
> CC: Marcel Holtmann
> ---
> I do not know if these files are just copied from linux-bluetooth upstream,
> so I am adding Marcel to CC anyway because he is mentioned in the copyright
> section.
It does appear that the files are a copy of the bluez package. If we're
fixing this on the PulseAudio side, I think we should include something
like diff below configure.ac, so that we can actually verify that the
mla instruction is available for the arch being used.
-- Arun
diff --git a/configure.ac b/configure.ac
index 08c947a..77e9823 100644
--- a/configure.ac
+++ b/configure.ac
@@ -257,13 +257,14 @@ case $host in
asm volatile ("ldr r0, %2 \n"
"ldr r2, %3 \n"
"ldr r3, %4 \n"
+ "mla r4, r1, r2, r3 \n"
"ssat r1, #8, r0 \n"
"str r1, %0 \n"
"pkhbt r1, r3, r2, LSL #8 \n"
"str r1, %1 \n"
: "=m" (a), "=m" (b)
: "m" (a), "m" (b), "m" (c)
- : "r0", "r1", "r2", "r3", "cc");
+ : "r0", "r1", "r2", "r3", "r4", "cc");
return (a == -128 && b == 0xaabb) ? 0 : -1;
]]),
[pulseaudio_cv_support_armv6=yes],
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
On Sat, 2011-02-19 at 13:28 +0200, Tanu Kaskinen wrote: > On Fri, 2011-02-18 at 15:11 +0530, Arun Raghavan wrote: > > Hello! > > > > On Tue, 2011-02-15 at 22:02 +0530, Arun Raghavan wrote: > > > Hey folks, > > > I've put up a draft proposed API changes to get passthrough support to > > > the point where things Just Work™ for at least the common cases, based > > > on previous discussion on-/off-list: > > > > > > http://pulseaudio.org/wiki/PassthroughSupport > > > > > > Please review/comment. Once we have some consensus, I'll send in patches > > > to actually get this done. > > > > I've updated this page with the changes discussed so far (and translated > > them into the actual API changes that we need). Please take a look and > > let me know if this looks acceptable. > > I think pa_encoding_t should include PA_ENCODING_ANY for the case where > a recording application doesn't care at all about the format. Check. > Maybe it would be better to leave out also the channel map from > pa_stream_new_extended()? The channel map is relevant only for PCM > streams, so putting it in the format info proplist would make sense in > my opinion. Agreed. > I believe there's no need to alter the pa_stream_connect_* functions in > any way. Returning the final format is not possible at the time when the > function returns - the API is asynchronous, so the function only sends a > request to the server, it doesn't get any response back. When the > response eventually comes from the server, the stream state changes to > PA_STREAM_READY, which triggers a callback in the client code. That > callback can then query the final format. A new function is needed for > that: Ah, I /knew/ I was forgetting something when I added that ... > const pa_format_info * const *pa_stream_get_format_info(pa_stream *s) > > My proposal is that the return value is a NULL-terminated list, for > supporting sink format querying in the future. For now the list will > always contain only one item. Another possibility would be returning > just a single format info instance here, and defining a separate > function for getting the format list in sink format query cases. Sounds good - I think the NULL-terminated list is preferable. Thanks Tanu, I've updated the page now. Cheers, Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] PA Roadmap Planning and LAC Conference
On Fri, 2011-02-18 at 23:00 +0200, Tanu Kaskinen wrote: > On Fri, 2011-02-18 at 11:15 -0600, Kurt Taylor wrote: > > Thanks for organizing this Colin! I will do my best to attend, but that is > > 5am (UTC-6) for me. > > It sounds like a few hours later would be better than the suggested > 11:00 UTC. Arun would probably be the first person to be annoyed by the > time being moved too much forward, but he's going to sleep at 21:30 UTC, > so there's plenty of headroom :) :) Indeed. If it helps, I created a little webthingummy to get everyone's preferences (we can add more options, but it seemed to me 24th was acceptable to all): http://www.doodle.com/ivx28di2kzztm2dt Cheers, Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
On Fri, 2011-02-18 at 11:04 +, Colin Guthrie wrote: > 'Twas brillig, and Arun Raghavan at 18/02/11 09:41 did gyre and gimble: > > Hello! > > > > On Tue, 2011-02-15 at 22:02 +0530, Arun Raghavan wrote: > >> Hey folks, > >> I've put up a draft proposed API changes to get passthrough support to > >> the point where things Just Work™ for at least the common cases, based > >> on previous discussion on-/off-list: > >> > >> http://pulseaudio.org/wiki/PassthroughSupport > >> > >> Please review/comment. Once we have some consensus, I'll send in patches > >> to actually get this done. > > > > I've updated this page with the changes discussed so far (and translated > > them into the actual API changes that we need). Please take a look and > > let me know if this looks acceptable. > > I've maybe missed the discussion, but is it worth having both: > pa_stream_new_extended > and > pa_stream_new_with_proplist_extended > > Doesn't the former just call the latter with a NULL proplist anyway? > > While I appreciate the symmetry with the existing API, I'd say avoid the > cruft and just call it pa_stream_new_extended() which implies both the > format and the proplist. WDYT? Good point - I agree with this. Also, fixed option c in the wiki. :) Cheers, Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
On Fri, 2011-02-18 at 03:42 -0700, Kelly Anderson wrote: [...] > The alsa driver has creates a /proc entry that lists the coding types > available for a particular device. It'd be nice if you would use that > for the list of supported coding types (at least for a default). I'm > not sure the list would be automatically updated if you unplugged a > device and plugged in a new device. The comprehensive list of supported > coding types is in alsa-kernel/pci/hda/hda-eld.c. I don't know how it works for HDMI, but if it does update that list based on the receiver, that would be ideal for us, since we should be able to probe that while routing. For S/PDIF, we don't have that option so I guess we'll need to add some additional checkboxes to GUIs so users can select what formats their receiver supports. -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
Hello! On Tue, 2011-02-15 at 22:02 +0530, Arun Raghavan wrote: > Hey folks, > I've put up a draft proposed API changes to get passthrough support to > the point where things Just Work™ for at least the common cases, based > on previous discussion on-/off-list: > > http://pulseaudio.org/wiki/PassthroughSupport > > Please review/comment. Once we have some consensus, I'll send in patches > to actually get this done. I've updated this page with the changes discussed so far (and translated them into the actual API changes that we need). Please take a look and let me know if this looks acceptable. Cheers, Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support (extending proplists)
On Wed, 2011-02-16 at 12:33 +, Colin Guthrie wrote:
> 'Twas brillig, and Arun Raghavan at 16/02/11 04:42 did gyre and gimble:
> > On Tue, 2011-02-15 at 12:33 -0600, pl bossart wrote:
> >>> Please review/comment. Once we have some consensus, I'll send in patches
> >>> to actually get this done.
> > [...]
> >> - The receiver may support the same format at different sampling
> >> frequencies (eg MPEG at 32, 44.1 and 48kHz but not any other for BT).
> >> We will need to list explicitly which sampling frequencies are
> >> supported for each format.
> >
> > This one will probably be somewhat contentious. I was going to put this
> > information in the format_info structure's proplist so clients can read
> > and match as they please. There is one stumbling block here in that
> > proplists do not allow list or range types.
> >
> > We can either support these by abusing the proplists a bit (for ranges
> > have a "prop.min" and "prop.max", for lists have "prop.num_elements",
> > "prop.elem_0", "prop.elem_1", etc.), using simple strings (the way
> > GstCaps are done) or add first-class list and range types. Listed in
> > increasing order of effort.
> >
> > IMO the first is too hacky. The second is quite flexible, but
> > potentially too generic? The third is the most disruptive, but also most
> > exactly suited to what we need.
> >
> > I'm leaning towards the second (string representation like "(type) [min,
> > max]" for range and "(type) { val1, val2, val3 }" for list). In the
> > current context, the type might be implicit in the key, but since this
> > literally becomes part of the API, I'd like to plan ahead.
> >
> > Thoughts?
>
> Random suggestion:
> 1. The range thing seems simple enough the prop.min and prop.max seems
> like an easy enough thing to list and support (perhaps even with a
> wrapper function if it saves a bit of sanity checking).
>
> 2. The lists are slightly harder, so how about we just support JSON
> style syntax here for simple array storage? i.e. "['val1','val2','val\'s
> beyond']" ? Again a wrapper function or two can help create/decode
> these? Using a format like JSON should be pretty simple and we could
> easily enough push out the whole proplist as a single JSON encoded thing
> at some point in the future if needed too.
We really should decide on what we need first, I guess :)
I assume that for a given property, the data type is implicitly
understood (this is how things work now).
The other thing to worry about is whether a given property should be
expected to only be either single-valued, a range or a list. This might
not be true - for example when querying a sink, you might get the
supported sample rates as a list, but when connecting, sample rate is
single-valued (we might not use properties to set the sample rate, but
as a generic data structure, I hope you see my point).
>From the API perspective, perhaps we could add an enum to represent the
type (single-valued, multi-valued, range), and then have an API to query
this (like pa_proplist_get_type(proplist, key)) that clients would use
if multiple possibilities exist. We can then have API for each type.
Implementation wise, I think it's nicer to just have one key and do some
string parsing for the range case as well.
One thing to note here is that we cannot support lists of strings since,
aiui, JSON requires that strings be enclosed in quotes and we do not
currently do this for single-valued strings. The json.org site is down,
so if I'm wrong, I blame Wikipedia. :)
-- Arun
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
On Thu, 2011-02-17 at 09:13 +, Colin Guthrie wrote: > 'Twas brillig, and Tanu Kaskinen at 17/02/11 07:45 did gyre and gimble: > > Your proposal would probably work well enough in practice, but I still > > would like more an approach where you create a stream and after it gets > > routed you finalize the stream format. > > Yeah, I agree with this statement. It just feels cleaner (my comment > about the format being used in the routing would still be an issue here > but I agree that it was probably an extreme example that wouldn't really > be needed in practice anyway). > > > If routing rules change before > > the format is decided, the daemon can tear down the stream and inform > > the client that it happened because of routing change. The client knows > > now that it should retry. In your proposal the client isn't aware that > > routing rules have changed, so it doesn't know why the connection fails. > > Also, even if connecting succeeds, but with different routing, the > > stream format that the client chooses may be suboptimal. > > > > So, my proposal is the following: > > > > Sinks have a list of format descriptions. One format description is a > > tuple consisting of the encoding type and some parameters that are > > characteristic for that encoding type. Depending on the parameter, a > > parameter value can be a single value, a range, a list or the parameter > > may be unset, meaning that anything is allowed. There should also be a > > special encoding type "any", that means that the client supports > > anything (useful for recording applications that just dump the stream to > > a file). > > > > When a client creates a new stream, it gives a similar list of formats > > as described above for sinks. The list must cover all formats that the > > client can support (usually the list contains only one tuple with only > > fixed parameters). The daemon routes the stream to some sink, and then > > the daemon takes an intersection of the sink formats and the stream > > formats. > > > > If the resulting set contains exactly one fixed format, then that is > > used for the stream. If the set contains more options than one fixed > > format, then the daemon decides the "best" format using some unspecified > > algorithm. If the set is empty, then the stream creation fails. > > When this fails, should we go back to the routing system and ask to be > routed again, but not to this failing sink? I can see this being a) > useful, but b) complicated (not so much complicated on initial > connection but complicated when a stream may get "re-routed" (i.e. when > a new, totally unrelated sink comes along, the routing system may > re-evaluate it's priority lists and try to move the stream to a higher > priority sink (i.e. the one that failed the first time). I probably didn't understand this correctly, but wouldn't this only be helpful if a new sink comes in exactly between when the routing fails and when you retry? -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
Hi Tanu, On Thu, 2011-02-17 at 09:45 +0200, Tanu Kaskinen wrote: > On Thu, 2011-02-17 at 02:54 +0530, Arun Raghavan wrote: > > On Wed, 2011-02-16 at 10:39 -0600, pl bossart wrote: > > > >> - I am not sure I understand how/when the query would be used. Seems > > > >> to me like a notification with the formats exposed by the sink > > > >> currently selected would be more usable. And if a change in routing > > > >> happens (new accessory, audio policy, etc), the client is informed and > > > >> can reconfigure to PCM if need be. > > > > > > > > In this scheme, how would the client first determine what formats are > > > > available? The notification will also be required - we can either > > > > piggyback in sink, sink-input and card change notifications, or > > > > introduce a new one for a change in available formats (I prefer the > > > > latter). > > > > > > The problem is that you don't know on what sink you will play until > > > you have actually created the pa_stream. The audio policy and routing > > > rules may kick in and if you query before you connect you would end-up > > > with a broken configuration. > > > > But the query API includes all the information that we can provide at > > stream creation/connect time, so things would only break if the query > > and connect are done with different parameters, or if the sink changed > > in the period between the two calls. It should be possible for clients > > to gracefully handle this and renegotiate. > > Your proposal would probably work well enough in practice, but I still > would like more an approach where you create a stream and after it gets > routed you finalize the stream format. If routing rules change before > the format is decided, the daemon can tear down the stream and inform > the client that it happened because of routing change. The client knows > now that it should retry. In your proposal the client isn't aware that > routing rules have changed, so it doesn't know why the connection fails. > Also, even if connecting succeeds, but with different routing, the > stream format that the client chooses may be suboptimal. > > So, my proposal is the following: Thanks for the detailed proposal! > Sinks have a list of format descriptions. One format description is a > tuple consisting of the encoding type and some parameters that are > characteristic for that encoding type. Depending on the parameter, a > parameter value can be a single value, a range, a list or the parameter > may be unset, meaning that anything is allowed. There should also be a > special encoding type "any", that means that the client supports > anything (useful for recording applications that just dump the stream to > a file). > > When a client creates a new stream, it gives a similar list of formats > as described above for sinks. The list must cover all formats that the > client can support (usually the list contains only one tuple with only > fixed parameters). The daemon routes the stream to some sink, and then > the daemon takes an intersection of the sink formats and the stream > formats. > > If the resulting set contains exactly one fixed format, then that is > used for the stream. If the set contains more options than one fixed > format, then the daemon decides the "best" format using some unspecified > algorithm. If the set is empty, then the stream creation fails. > > The client can also choose not to specify any formats. In that case the > routing logic can't use the format as input for decisions, but currently > there's no such routing logic anyway. After routing is done, the stream > enters to a new state, PA_STREAM_ROUTED. In this state the client has to > query the set of formats that the sink supports, and decide the final > format. When the client sets the format, the stream changes state to > PA_STREAM_READY. This sounds pretty clean overall, and after talking to Wim on IRC for a bit, I think we might even be able to do without the no-formats variant of the API. That said, it would be nice to have the last bit as well, so I'll keep it put it down as something to add after the basic bits are done. I've updated the wiki with this version now. Cheers, Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
On Thu, 2011-02-17 at 10:26 +0200, Tanu Kaskinen wrote:
> On Wed, 2011-02-16 at 19:17 +0530, Arun Raghavan wrote:
> > > Can you elaborate on what you had in mind regarding UIs?
> >
> > As for UIs, it would probably be nice to have some sort of (hidden by
> > default) way to show supported format in a sink. Of course, pactl/pacmd
> > would expose this data too. Other than informative purposes, it would
> > also make debugging simpler ("Hey, my BT headset isn't playing MP3s
> > automatically" .. "Can you check if it's actually supported using these
> > simple steps?")
>
> Yes, the supported formats should be provided in the sink introspection
> data. This isn't necessarily relevant when creating streams, though.
Ah, right. I was squashing things that aren't really related.
[...]
> I would suggest that the sinks and the clients use the same presentation
> for describing the supported formats. It may be a proplist or something
> else. In a purely proplist-based solution there may be no need to extend
> the stream creation API. However, a purely proplist-based solution would
> look hacky to me, but that's a matter of taste.
>
> If I had to decide the format set representation now, I might do it as
> follows:
>
> typedef enum pa_encoding {
> PA_ENCODING_PCM,
> PA_ENCODING_MP3,
> ...
> }
>
> typedef struct pa_format_desc {
> pa_encoding_t encoding;
> pa_proplist *params; /* string -> string: parameter name
> * to parameter value. The parameter
> * value has syntax for representing
> * also lists and ranges. Missing
> * parameter means that anything is
> * allowed, unknown parameters are
> * ignored. */
> } pa_format_desc;
>
> Uh, that ended up pretty identical to your pa_format_info proposal, even
> though I didn't mean to :) I tried to replace the proplist with a
> solution that doesn't require any string parsing, but that ended up very
> complicated.
Good to see we converged on the same structure. :)
Building on the pa_sample_spec naming, pa_stream_spec,
perhaps?
> I'm proposing that a new function is added for creating streams that
> takes a list of pa_format_desc structs (or maybe pa_format_info is a
> better name) instead of sample spec and channel map.
Rethinking this, I'm starting to agree with you and Pierre on this. For
the PA_ENCODING_PCM, the proplist would basically just encode the same
data that's in pa_sample_spec. For other formats, we can add the data we
need.
I'm researching you other proposal and will update the proposal on the
wiki with both these in a while.
-- Arun
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
