Re: [pulseaudio-discuss] gst pulsesrc and default caps
On Mo, 2010-08-16 at 07:58 +0300, Tanu Kaskinen wrote: Correcting myself: On Mon, 2010-08-16 at 06:42 +0300, Tanu Kaskinen wrote: I guess the problem is that pulsesrc doesn't know which source is going to be used before actually starts recording. No, that's not the problem. The problem is that pulsesrc doesn't use the proper flags when creating the stream: PA_STREAM_FIX_FORMAT, PA_STREAM_FIX_RATE and PA_STREAM_FIX_CHANNELS can be used to create the stream with whatever parameters are used by the device that the stream connects to. Thank you!!! i like this answer :D Regards, Alexey ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] Packagers: Xlib vs XCB
Hi, As some of you will have found out, there are some applications that have problems relating to Xlib usage (XCloseDisplay() IIRC) when combined with PA client libs (notably I've seen reports from VLC relating to this). I've therefore committed a patch I wrote a while back to stable-queue that ports the client side code to XCB. I've been using this for a while and not noticed any regressions so I think it's good for s-q. I want to push it on master too, but there was some extra code added there that deals with multiple screens. I'm waiting for a reply on ticket 799 to see if this can be mangled into my port, but if I don't get one soon, I'll just clobber it with my code and the missing functionality can be added back in later (it's a pretty niche use case IIRC). So if you package s-q, don't forget to add a build require on XCB-devel package if you want X11 support :) Cheers Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] gst pulsesrc and default caps
On Mon, 2010-08-16 at 06:42 +0300, Tanu Kaskinen wrote: I guess the problem is that pulsesrc doesn't know which source is going to be used before actually starts recording. No, that's not the problem. The problem is that pulsesrc doesn't use the proper flags when creating the stream: PA_STREAM_FIX_FORMAT, PA_STREAM_FIX_RATE and PA_STREAM_FIX_CHANNELS can be used to create the stream with whatever parameters are used by the device that the stream connects to. Thank you!!! i like this answer :D I don't think that solves the problem. The performance issue is due to the format/sample-rate conversion. Using these flags essentially mean that you will record with whatever native sampling-rate is used by the pulseaudio source (as specified in daemon.conf) no matter what value is specified when the stream is created.. It doesn't mean you are going to record at 16kHz natively in pulseaudio. You will still have to go your src in gstreamer. -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] These ideas I've had for the better part of a month, forgive me for there length.
The next stream type should be a pulse audio internal type(s) used for the mixing of mp3/ac3 and perhaps dts streams. It's my understanding that ac3 uses vectors to describe 6 channels of sound much like a 2ch mp3. If I'm not mistaken these vectors can be combined mathematically as-is to represent the combination of two sounds. This would be a great achivement over any uncompress/combine/recompress senerio. Do you have any pointers to how this is done? If it's true that there really is a way to mix compressed streams without uncompressing first, then maybe volume adjustment is possible too? Nah. no way you can mix streams without decompressing (dequantization+inverse transform). The only thing you could do is mix in the transform domain if both streams used the same transform and window size, not a very common case. -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] gst pulsesrc and default caps
On Mo, 2010-08-16 at 09:06 -0500, pl bossart wrote: On Mon, 2010-08-16 at 06:42 +0300, Tanu Kaskinen wrote: I guess the problem is that pulsesrc doesn't know which source is going to be used before actually starts recording. No, that's not the problem. The problem is that pulsesrc doesn't use the proper flags when creating the stream: PA_STREAM_FIX_FORMAT, PA_STREAM_FIX_RATE and PA_STREAM_FIX_CHANNELS can be used to create the stream with whatever parameters are used by the device that the stream connects to. Thank you!!! i like this answer :D I don't think that solves the problem. The performance issue is due to the format/sample-rate conversion. Using these flags essentially mean that you will record with whatever native sampling-rate is used by the pulseaudio source (as specified in daemon.conf) no matter what value is specified when the stream is created.. It doesn't mean you are going to record at 16kHz natively in pulseaudio. You will still have to go your src in gstreamer. -Pierre It looks like it working for me. Or resample method: (null) mean some thing other? 1 source outputs(s) available. index: 0 driver: protocol-native.c flags: START_CORKED FIX_FORMAT FIX_RATE FIX_CHANNELS state: RUNNING source: 2 alsa_input.usb-046d_0991_9671DCEE-02-U0x46d0x991.analog-mono current latency: 0,00 ms requested latency: 27,56 ms sample spec: s16le 1ch 16000Hz channel map: mono Mono resample method: (null) owner module: 9 client: 33 gst-launch-0.10 properties: media.name = Record Stream application.name = gst-launch-0.10 native-protocol.peer = UNIX socket client native-protocol.version = 16 application.process.id = 13431 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] Wait on sound cards before starting PA, and stream routing
We had a problem with PA a few days ago which I analyzed as the following: PA started up for the first time, i e without a .pulse directory. Due to racy startup conditions (we're all trying to boot up as quick as possible nowadays), sometimes the start order was as follows: 1) Sound card #2 was probed and announced from the kernel 2) PA was started up and found sound card #2 3) Some client or module asked for the fallback/default device 4) Since there was no current default device, it was auto-set to sound card #2 5) Sound card #1 was probed and announced from the kernel, but was not selected as default - even if the priority was higher, since the default had already been set. My workaround was to write a simple wait-on-file-access module that waited for /dev/snd/controlC0 and /dev/snd/controlC1 before continuing, and then I placed that one on the top of /etc/pulse/default.pa for this particular hardware. I found it the least ugly workaround at the time, and should upstream be interested in merging this module, I'd be happy to prepare a git patch for either master or stable-queue as you see fit. The long-term solution - and this is more my own thoughts than an official standpoint from Canonical - probably would include writing something that takes on the entire problem of deciding stream routing, because now we have many modules which all try to solve their piece of the puzzle, but instead end up shooting each other's feet. I know Colin have done a lot of work in this area already (thank you Colin!), and so Colin, it would be nice to have a little status update: - Did the implementation turn out the same way you described in your February blog post? - Is this ready for testing in pulseaudio git master? - What remains until this is ready for everyday usage? -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Rate/Timing issues when streaming over BT from iPhone.....
This is a known issue with module-loopback. If you look at this part of the log, you'll see that there's something really wrong with how the sample-rate is set: I: module-loopback.c: Old rate 43236 Hz, new rate 43300 Hz I: module-loopback.c: Loopback overall latency is 99.98 ms + 806.05 ms + 39.69 ms = 945.71 ms I: module-loopback.c: Should buffer 34640 bytes, buffered at minimum 69240 bytes I: module-loopback.c: Old rate 43300 Hz, new rate 44965 Hz I: module-loopback.c: Loopback overall latency is 99.98 ms + 781.78 ms + 40.83 ms = 922.60 ms I: module-loopback.c: Should buffer 35976 bytes, buffered at minimum 134708 bytes I: module-loopback.c: Old rate 44965 Hz, new rate 46568 Hz I: module-loopback.c: Loopback overall latency is 99.98 ms + 429.80 ms + 40.62 ms = 570.40 ms I: module-loopback.c: Should buffer 37256 bytes, buffered at minimum 79028 bytes I: module-loopback.c: Old rate 46568 Hz, new rate 45144 Hz I: module-loopback.c: Loopback overall latency is 100.00 ms + 409.27 ms + 41.85 ms = 551.11 ms I: module-loopback.c: Should buffer 36120 bytes, buffered at minimum 73904 bytes I: module-loopback.c: Old rate 45144 Hz, new rate 45044 Hz By changing the sample-rate so often you end-up with cracks/noises. I had similar problems when using an RTP link, the oscillations on the sample-rate are not good. Fundamentally I think there's something wrong with the logic Lennart added to my original code. Every 5s or so, a timer fires, and a message LATENCY_SNAPSHOT is sent to the input and output thread. Then once both answers are received, the code determines what the sampling rate should be. What I think is flawed is that this is not an atomic way of getting the latency on both sides, and since we receive packets the latency varies by large steps unlike for ALSA sinks/sources. Without some filtering you end-up with too many variations of the sampling rate. Bottomline: this loopback code deserves some love, unfortunately I don't have time to look into this. I had some success by limiting the sample-rate oscilllations to 100Hz around the nominal value. -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Wait on sound cards before starting PA, and stream routing
'Twas brillig, and David Henningsson at 16/08/10 20:38 did gyre and gimble: We had a problem with PA a few days ago which I analyzed as the following: PA started up for the first time, i e without a .pulse directory. Due to racy startup conditions (we're all trying to boot up as quick as possible nowadays), sometimes the start order was as follows: 1) Sound card #2 was probed and announced from the kernel 2) PA was started up and found sound card #2 3) Some client or module asked for the fallback/default device 4) Since there was no current default device, it was auto-set to sound card #2 5) Sound card #1 was probed and announced from the kernel, but was not selected as default - even if the priority was higher, since the default had already been set. My workaround was to write a simple wait-on-file-access module that waited for /dev/snd/controlC0 and /dev/snd/controlC1 before continuing, and then I placed that one on the top of /etc/pulse/default.pa for this particular hardware. I found it the least ugly workaround at the time, and should upstream be interested in merging this module, I'd be happy to prepare a git patch for either master or stable-queue as you see fit. The long-term solution - and this is more my own thoughts than an official standpoint from Canonical - probably would include writing something that takes on the entire problem of deciding stream routing, because now we have many modules which all try to solve their piece of the puzzle, but instead end up shooting each other's feet. I know Colin have done a lot of work in this area already (thank you Colin!), and so Colin, it would be nice to have a little status update: - Did the implementation turn out the same way you described in your February blog post? - Is this ready for testing in pulseaudio git master? - What remains until this is ready for everyday usage? Well I've not had much time to make practical progress. Primarily because I couldn't finish off the discussions regarding it with Lennart. There are still several threads hanging on the list that really need his input, but due to systemd distractions he's not had time lately. I didn't want to start any solid implementations if the general concept was not acceptable to Lennart. I still believe that personally the approach I outlined is a valid one and the right way forward, with the only significant problem being no longer able to move an individual stream from a given application to a different device than all other streams of that application (that's not strictly true, but I wont go into the details right now (mainly because I've forgotten them and I'd need to look up the mail archive :D) - but it's easily mitigated at the application level for those few apps that need multiple independent streams via the use of proper role tagging or by setting a different identifier for that particular stream). Overall it's no more a limitation than currently where a track-change or some other tear-down/recreation of the sink-input would result in an unwanted/unexpected device change (i.e. it's broken now anyway, but in a different way that *appears* to work at first glance, but will fail at some point in the future anyway). But the proposal was quite different to how things work now and I really do need to sit down with Lennart and ensure that it's going to be accepted before I (or anyone else) crack on with the implementation. The last comment I think Lennart made on the topic was still referring to the stream-restore-id property which was something that was factored out completely, so really need to make sure that point is understood properly before we can discuss further. Lennart, if you're able to set aside a couple hours or so for such a discussions please let me know and we can schedule in a time when we're both available? Going back to your specific problem, it sounds like it would indeed be solved/worked around by the approach I outlined, so it probably is the right way forward. I don't really expect the implementation to take all that long once the principles of operation are agreed upon. Hope that helps. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
