Re: [pulseaudio-discuss] [PATCH v2] core-util: Fail if XDG_RUNTIME_DIR belongs to someone else
Le 2014-09-08 14:32, David Henningsson a écrit :
Usually, PA will use the PULSE_SERVER X11 property instead of using
XDG_RUNTIME_DIR,
so this environment variable does not matter.
If this property is not available, or if one is using the pacmd cli
protocol,
the client will go ahead and call pa_make_secure_dir on
XDG_RUNTIME_DIR/pulse.
This will either fail (if you're another regular user), or succeed
(if you're root).
Both scenarios are bad - failing will cause the connection to fail,
and succeeding
is even worse, as it can cause *other* connections to fail (as the
directory
ownership has changed).
Instead fail and complain loudly.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=83007
Signed-off-by: David Henningsson david.hennings...@canonical.com
---
src/pulsecore/core-util.c | 8
1 file changed, 8 insertions(+)
v2: Don't blame systemd anymore. Make error message translatable.
diff --git a/src/pulsecore/core-util.c b/src/pulsecore/core-util.c
index d7a95d6..6bb6317 100644
--- a/src/pulsecore/core-util.c
+++ b/src/pulsecore/core-util.c
@@ -1816,6 +1816,14 @@ char *pa_get_runtime_dir(void) {
/* Use the XDG standard for the runtime directory. */
d = getenv(XDG_RUNTIME_DIR);
if (d) {
+struct stat st;
+if (stat(d, st) == 0 st.st_uid != getuid()) {
This looks like a case of ToCToU to me.
In principles, you should probably use open() then fstat(), and then
openat to create or access files within the directory.
+pa_log(_(XDG_RUNTIME_DIR (%s) is not owned by us (uid
%d), but by uid %d!\n
+ (This could e g happen if you try to connect to
a non-root PulseAudio as a root user, over the native protocol. Don't
do that.)),
+ d, getuid(), st.st_uid);
+goto fail;
+}
+
k = pa_sprintf_malloc(%s PA_PATH_SEP pulse, d);
if (pa_make_secure_dir(k, m, (uid_t) -1, (gid_t) -1, true)
0) {
--
Rémi Denis-Courmont
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Per-client flat-volumes control
Le 2014-08-06 11:45, Tanu Kaskinen a écrit : 3) Add a second volume control to streams, one which represents the stream's own volume only, i.e. never flat volume. Applications that want to avoid flat volume can use that volume control instead of the primary volume control. Looking beyond HTML5, could that also cover per-stream replay gain? I mean, can applications both set the normal stream volume (as per user interaction) and the second stream volume (as per something else), and expect things to work? -- Rémi Denis-Courmont ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Per-client flat-volumes control
Le 2014-08-06 16:10, Tanu Kaskinen a écrit : The answer to your question: no, the normal stream volume and the relative volume are very tightly tied together (and when flat volumes are not in use, they're exactly the same thing). You can't change one without affecting the other, and both are expected to be user-controlled. Then I don't really see how and why the PulseAudio daemon would have to care about that new volume. The browser can simply divide/multiply the stream volume by its source/sink volume if the flat volume flag is on. You might or might not want to provide libpulse-level helpers for it, but that's pretty much it, AFAICT. -- Rémi Denis-Courmont ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] How to change the volume in PulseAudio (libpulse)
Le 2014-05-07 23:50, Ibrar Ahmed a écrit : I am writing a program to play audio using libpulse on linux. I have successfully played the audio, but need to know how to change the volume. I am able to start the stream using v = PA_VOLUME_NORM; pa_cvolume_set(m_lcvolume, 1, v); pa_stream_connect_playback(s, NULL, attr, PA_STREAM_NOFLAGS, m_lcvolume, NULL) You should not force the volume to a hard coded value at start. That will mess up the system mixer, especially unless flat volumes are disabled. Only pass a volume to pa_stream_connect_playback() based on direct user input. -- Rémi Denis-Courmont ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] pulse client implementation
On Wed, 26 Mar 2014 19:22:50 +, Pete Beardmore pete.beardm...@msn.com wrote: specifically, the scenario whereby a user has explicitly configured the app (via config file - read on initialisation) to use 'sinkX', and then at some point during their 'session' (by which i mean 'time up until the binary is killed'), has moved the app's current stream to an alternative sink, 'sinkY'. finally, playback is stopped and restarted the question is, which sink should be used for the new playback stream? Well... the sink that the user expects to be used should be used. the two takes on this were: 1. the user explicitly specified 'sinkX' in the configuration, so that's where it should play next 2. the user explicitly moved the playback to 'sinkY', so that's where it should play next Both approaches have their logic. Neither will satisfy every user. As Tanu says, it might be yet better to not have a persistent device settings for PulseAudio within the application at all. That's the path I took with my application (VLC media player). In addition, if the user selects a specific sink in the UI while there is no audio stream, we retain until the next audio stream starts or the application exits. This is not perfect: 1) We do not know what sink to hilight in the list of sinks when there is no audio stream - unless the user explicitly selected one sink via the GUI. 2) If the user selects a sink in the GUI, then exits the application without starting an audio stream, we forget the user setting completely. -- Rémi Denis-Courmont Sent from my collocated server ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Is it possible to connect to an existing stream using pulse audio?
On Thu, 7 Nov 2013 11:48:19 +0530, sathishkumar sivagurunathan sathish1...@gmail.com wrote: Hello, My aim is as follows. 1) I have a audio player like Vlc running. I have checked with PAMAN command that VLC as a client and a stream with stream name is created. My intention is to connect to this pretty existing stream. You cannot connect to an existing stream. A stream is connected by its client to the server and that is all as far as connecting is concerned. To manipulate another client's stream, you need to use the introspection functions related to sink inputs. Basically, that is what the PulseAudio-based mixer applications do: you can move a sink input to another sink, change the volume, mute state and balance of the sink input or kill the sink input. I think it should be pretty obvious, but there are no ways for PulseAudio to pause a stream. The playback state machine of VLC or Totem is in VLC and Totem, not in PulseAudio. All PulseAudio can do is advise the application that its stream is preempted and thus the application _should_ pause. -- Rémi Denis-Courmont Sent from my collocated server ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] pulseaudio daemon not responging
On Thu, 22 Nov 2012 23:05:15 +0200, Tanu Kaskinen ta...@iki.fi wrote: On Thu, 2012-11-22 at 20:38 +0200, Stefan Stefanov wrote: http://thread.gmane.org/gmane.comp.audio.pulseaudio.general/11000 Exactly the same problem as mine. 1. Build of pulseaudio failed without libpthread-stubs.so with no such file ... 2. I noticed that in crux linux, sem_wait() resides in libpthread_stubs.so, and it is found through call to libpthread.so, but in my arch linux box there are no libpthread_stubs.so at all. So, I think that sem_wait() (in my arch linux box) resides in libpthread.so. Is it possible to upgrate libpthread.so? Which package I must upgrade? I cannot just delete libpthread-stubs.so. libpthread is provided by the libc implementation (eglibc on Debian). libpthread-stubs is completely separate (developed by the XCB project, apparently). I don't know how libpthread-stubs works, how it replaces libpthread in the linking process, so I don't know what could cause pulseaudio to be linked against libpthread-stubs, and I don't know what you should do. libpthread-stubs uses weak symbols. If the process links against libpthread, then the libpthread symbols will be used. Otherwise, the unthreaded stubs will be used. Obviously, libpthread-stubs does not provide pthread_create(). However, on GNU/Linux, pthread-stubs is usually nothing but a pkg-config stub. (e)glibc provides weak pthread symbols natively in libc.so, so there is no need for pthread-stubs. Regardless, PulseAudio should NOT be linked to pthread-stubs since it uses pthread_create(). -- Rémi Denis-Courmont Sent from my collocated server ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 1/6 v3] core: Initialize ARM NEON code if available
On Tue, 16 Oct 2012 10:49:34 +0530, Arun Raghavan arun.ragha...@collabora.co.uk wrote: 3. How shall we go about enabling this code? Have a configure time check for some instructions that are needed, build it in if available, and then run-time detection should pick the right code path? GCC does not support the target function attribute on ARM, so NEON cannot be enabled selectively, on a per function basis. As a consequence, intrinsics and inline assembler cannot be used for run-time-conditional NEON code: the code will only compile if NEON is enabled in CFLAGS. Yet if NEON is enabled in CFLAGS, the compiler may emit NEON instruction for plain C code such that the code will not run at all on processors without NEON. So .S/.s assembler source files constitute the only way to write run-time-conditional NEON code for the time being. Just make sure you did _not_ enable NEON in the CFLAGS and enable it manually with the .fpu neon assembler directive. Personally, I much prefer .S/.s file over inline asm because I find them more readable, but it's a matter of taste. -- Rémi Denis-Courmont Sent from my collocated server ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 1/6 v3] core: Initialize ARM NEON code if available
On Wed, 17 Oct 2012 16:10:49 +0200 (CEST), Peter Meerwald pme...@pmeerw.net wrote: Hello, Surprise! I'm reviewing this now. :p indeed :) 1. v3 drops intrinsics in favour of inline asm -- is that for performance reasons? I noticed performance issues with certain compiler versions; inline asm offers more control/defined output; further, alignment annotations are not available with intrinsics -- currently they are not used because I'm not sure about the alignment guarantees of certain PA buffers; intrinsics could probably be added later if there is enough interest First thing you should prefetch data (PLD). Then you should schedule and unroll the code. Only last, bother optimizing aligned load/store. 2. In the mono-stereo float case, the Cortex A9 code is actually slower. I recall that in a previous thread, we had this sort of situation on one of Panda/Beagleboard. Do we need some way to pick and choose implementations? I only have beagleboard-xm and pandabaord available as test platforms (Cortax A8 and A9, resp.) PATCH 2/6 now tests for A8 vs A9/A15/Axxx and chooses code accordingly another issue is benchmarking: relative performance is different depending on the length of the buffers processed, whether they are cached I'd read the Cortex-A8 instruction timing first to see how much unrolling is needed. Otherwise, the implementation will be so far off from the optimum that benchmarking is a bit silly. my target task involves stereo recording, resampling, int/float conversion, stereo-to-mono and mono-to-stereo mapping and I am seeing good speedups on both beagle- and pandaboard I need to check the downmix to mono behaviour after ff4af902cf4ac07c5f1da3b6dacbb3195c7c222d resampler: Fix volume on downmix to mono 3. How shall we go about enabling this code? Have a configure time check for some instructions that are needed, build it in if available, and then run-time detection should pick the right code path? I'd suggest to model after bluetooth/sbc: compile the *_neon.c files always but only activate the NEON code if defined(__ARM_NEON__) disadvantage is that we cannot have a common executable for NEON/non-NEON ARM CPUs -- I don't think this is a big constraint Remi Denis-Courmont suggests to use .s assembler files to overcome this issue; this would necessitate some configure options as well With .s files, you can override the target FPU inline (.mfpu neon), overcoming the __ARM_NEON__ problem. As an alternative, you could compile all the intrinsic and inline assembler in a separate static import library (noinst_LTLIBRARIES). Then you can pass different CFLAGS than for the rest of the project. interestingly, on x86/AMD64 gcc can emit MMX/SSE code in inline asm even when the compiler itself is not enabled to generate such instructions -- hence no .s files in PA so far Yes and no. You can emit MMX/SSE irrespective of compiler flags, but you cannot specify MM and XMM registers in the clobber list unless MMX and SSE 1 are enabled respectively. Thus, you end up with potentially invalid byte code. This is especially likely to break when you compile for x86-64 where GCC uses SSE for regular floating point operations. However, on x86, you can enable MMX or SSE on a per-function basis: __attribute__((target(mmx))) __attribute__((target(sse))) Alas, this not supported on ARM so far. at runtime there already is an env. var PULSE_NO_SIMD to disable optimized code path; further the output of /proc/cpuinfo is parsed to see if NEON is available (kind of pointless since it is a compile-time decision) Yes, it is pointless as there is no warranty that the code will run on non-NEON processors. -- Rémi Denis-Courmont Sent from my collocated server ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 1/6 v3] core: Initialize ARM NEON code if available
Le mercredi 17 octobre 2012 20:37:15, Thomas Martitz a écrit : Am 17.10.2012 10:53, schrieb Rémi Denis-Courmont: So .S/.s assembler source files constitute the only way to write run-time-conditional NEON code for the time being. Just make sure you did _not_ enable NEON in the CFLAGS and enable it manually with the .fpu neon assembler directive. Personally, I much prefer .S/.s file over inline asm because I find them more readable, but it's a matter of taste. You could also write in .c files and compile them with different CFLAGS (through make), but the result is the same. With automake, CFLAGS is per-target, not per-source. -- Rémi Denis-Courmont http://www.remlab.net/ ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v2 1/6] gccmacro: Disable printf-like format checking on mingw32 compilers.
Le mardi 21 août 2012 14:32:06 Thomas Martitz, vous avez écrit : Am 21.08.2012 08:51, schrieb Rémi Denis-Courmont: Le mardi 21 août 2012 00:50:34 Thomas Martitz, vous avez écrit : There are tons of warnings, most of them because the function is not recognized as printf-like. Removing checks looks very fishy. To use C99 and/or GNU format specifiers on MingW, you need to use the gnuprintf attribute instead of printf. With printf, the format string is validated according to the antiquated MSVC rules. Interesting, I didn't know about gnuprintf. FWIW, what are those antiquated MSVC rules? The ones from C89. -- Rémi Denis-Courmont C/C++ software engineer looking for a job http://www.linkedin.com/in/remidenis ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Virtual source
On Fri, 10 Aug 2012 14:38:56 +0200, Geir Birkedal g...@sqhead.com wrote: I am writing a program that produces an audio signal and currently plays it back using the simple API. This works fine. My problem is, instead of playing the audio out, I want to pipe it to a virtual input device, and use it as input to other applications. Did you consider using the loopback ALSA driver? The device should be visible to PulseAudio, shouldn't it? -- Rémi Denis-Courmont Sent from my collocated server ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 0/4] Volume ramping
Le mercredi 8 août 2012 11:44:51 Alexander E. Patrakov, vous avez écrit : 2012/8/8 Jaska Uimonen jaska.uimo...@helsinki.fi: Not because it would take more resources, but because of it is hidden sw volume. Just for the record: i'd say that it is good exactly for those situations where you want a hidden volume that does not affect any slider in the mixer application. Yeah, so would I. In fact, I would like to export the replay gain to PA instead of applying it manually in the application. -- Rémi Denis-Courmont, looking for a job http://www.remlab.net/ http://fi.linkedin.com/in/remidenis ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [alsa-devel] Immediate underrun with PulseAudio ALSA plugin when PA and ALSA buffer sizes differ
Le jeudi 19 juillet 2012 11:56:09 David Henningsson, vous avez écrit : So how do we solve this? Well, I believe the best fix would be to fix PulseAudio to give back underruns later, i e, not until we know for sure that the 221 frames have been played back. Right now we send it out when the client buffer is emptied, which is too early. Deferring the underrun on the PulseAudio side would give the client side a fair chance to fill up PulseAudio's big buffer and thus avoid the underrun. I remember VLC having some trouble with this behaviour as well. This would, however, be some work in PulseAudio to get right. :-/ Previously, VLC would assume an underrun meant a glitch and was thus a good opportunity to resync the hard way (that is to say, immediately and without resampling). Nowadays, VLC just ignores PulseAudio underruns events, except for printing a debug message. -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] SDP LF vs. CRLF
Hello, Le jeudi 19 juillet 2012 01:41:52 Christian K., vous avez écrit : I'm currently trying to connect PulseAudio with VLC using RTP. The SDP sent by VLC is not parsed by PulseAudio, the error is invalid header. I discovered that PulseAudio seems to expect that the SDP descriptor contains just LF i.e. \n line breaks whereas VLC is sending CRLF line breaks as it is also specifiied in the RFC [1]. To be precise, the RFC requires writing CRLF and reading both CRLF and LF. Jon Postel principle applies. Clearly, there is a PulseAudio bug. Note though that: - PulseAudio also fails to use the standard SAP multicast group addresses, so it will not interoperate with VLC out of the box. - In the VLC-PulseAudio direction, VLC must be configured to transcode to 's16b', as PulseAudio is not able to decode non-linear audio commonly found in RTP. Regards, -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Building PulseAudio 2.0 without a dependency on libstdc++
Le lundi 16 juillet 2012 06:41:11 Louis Opter, vous avez écrit : How could I patch the Makefile to not link with the libstdc++ when WebRTC is not used? And, should I file a bug for this? You may be hitting a limitation of automake. If there is any single .cpp file in the sources of a given target, even if it is a conditional and unselected source, the C++ linker will be used. -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Transitioning from pa_bool_t to C99 bool
On Mon, 02 Jul 2012 08:45:42 +0200, David Henningsson david.hennings...@canonical.com wrote: It might make sense to keep something like #ifndef HAVE_STD_BOOL typedef int bool; I sincerely don't recommend that kind of hacks. int and bool are completely different things. The representation in memory may be different depending on the ABI. Furthermore, the conversion rule for the compiler are not the same. That can introduce subtle bugs on old compilers. I think it's best to fail explicitly than to hide bugs. -- Rémi Denis-Courmont Sent from my collocated server ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] pulseaudio-discuss Digest, Vol 13, Issue 46
Le lundi 28 mai 2012 22:34:32 Drew, vous avez écrit : On Mon, May 28, 2012 at 3:00 PM, pulseaudio-discuss-requ...@lists.freedesktop.org wrote: The log just shows that the latency estimation that PulseAudio provides to VLC are unstable, showing a steep increase at nominal playback speed. If it keeps on happening all the time, something is clearly broken. It could be the audio hardware, the computer clock, the audio driver, PulseAudio or VLC. Being unable to reproduce your problem, I would not hazard a guess. I've now confirmed identical behavior with mplayer (using SMPlayer as front end). It also happens with system sounds as well intermittently. Then it's not a VLC problem thus I cannot help you. It is likely not even a PulseAudio problem either. All I can say is, check your audio hardware and driver is working and configured correctly. Alas even today, some cheap audio hardware still need some manual kernel parameters to operate properly. Many thanks for the response. I'm more than happy to post logs/files as needed to help someone more familiar with this issue debug the problem. Best of luck with that but don't hold your breath... -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] ARM NEON patches
Le vendredi 10 février 2012 19:13:38 Peter Meerwald, vous avez écrit : -mfpu=neon, then the compiler assumes the code will run ONLY on NEON-capable ARM devices. If you want to do run-time detection, you MUST NOT pass the corresponding compiler flag. (The same is true of MMX and SSE by the way.) so the simple solution is to - drop the runtime check - use NEON if the compiler provides NEON if the code has to run on non-NEON platforms, NEON support cannot be enabled in the compiler Correct. the more involved solution is to - have the runtime check in place - compile code with different compiler flags - make a decision at runtime and call different code path Right. It's much easier for dedicated assembler source code that inline assembler or intrinsics, as you can simply override the FPU in the source: .fpu neon In GCC, the target function attribute would address this problem nicely, but it is not supported on ARM -only x86- at the moment, to my knowledge :-( in PulseAudio, the MMX/SSE code path use inline assembler; surprisingly (for me at least), gcc happily compiles inline assembler SSE/MMX code even with -march=i386, i.e. arch=i386 does not get passed to the assembler I think that is a grand-fathered bug in x86 GCC. But even then, the compiler will reject MMX or SSE registers in the clobber list of the inline assembler. Without a valid clobber list, you cannot safely write inline assembler. As long as the MMX and SSE registers are not used for anything else in the same thread, it works. Then one day, someone compiles the software with SSE for FPU computations or whatever, and it explodes due to registers corruption. So from my point of view, run-time MMX and SSE selection is just as hard as ARM NEON's. The only extra nicety is GCC 4.4 per-function target attribute: __attribute__((__target__(mmx))) __attribute__((__target__(sse))) which enable MMX or SSE on a per-function basis. Then you can include the mm or xmm registers in the clobber list. So there's no need to fiddle with compiler flags. PulseAudio simply assumes that the compiler is recent enough to know about MMX/SSE, there is no compile-time probing or checks such as #ifdef __SSE__ (fair enough) That's probably wrong. In VLC, we have had cases of corrupted builds depending on the compiler flags, while doing making that assumption. to take this solution, some build infrastructure is needed; it might be required as well for the SSE3 resampler patches in discussion this means: - probe compiler flags (such as -msse2, -mfpu=neon) - probably configure options to override - passing different compiler flags to different compilation units which route shall we go? -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] detection of SSE3 support in configure.ac
Le mardi 6 décembre 2011 13:00:16 Nallasellan, Singaravelan, vous avez écrit : I have an optimized SSE-based resampling library that I bolted in PulseAudio. It was measured to bring a 2x speed-up over speex, mainly because it uses fixed-tables instead of interpolations, the price being that it can only be used for fixed-rate sinks/sources. Since it's hardware-specific, I'd need a means to enable/disable it at compile time, using some kind of voodoo magic in configure.ac. Does anyone have pointers on SSE detection logic? To make things safe, I also detect SSE at run time but would like to disable it completely for other non-x86 or older platforms. CPUID processor instruction should provide all the details about the processor. CPUID is not a complete solution. It will tell you whether the CPU supports certain instruction sets. But it does not specify whether the operating system supports the SSE registers xmmX. Thus parsing /proc/cpuinfo is more reliable though obviously Linux-specific. -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Screen casting with PulseAudio
On Tue, 18 Oct 2011 13:38:39 +0200, Michał Sawicz mic...@sawicz.net wrote: Dnia 2011-10-18, wto o godzinie 13:33 +0200, Rémi Denis-Courmont pisze: Eh? The user doing the recording typically wants to hear the sound while recording. So I don't see what null sink has to do here. As long as you only want to record your speakers, then just record the monitor of the output sink. The null / loopbacks can help if you want to record microphone, too. Obviously that's not relevant to VLC itself, it's through pactl/pacmd (sorry) and pavucontrol that you need to select the appropriate recording source. So that's not an answer to the problem. Yes it is. VLC isn't the place to choose recording inputs. Volume control tools are the place to do so. Can you describe your complete usecase? 'Cause I fail to see the actual issue at hand. If the user has selected I want to record (or stream) my desktop, how does the application get hold of the desktop audio? In other words how should it select a sink monitor source? -- Rémi Denis-Courmont http://www.remlab.net/ ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Screen casting with PulseAudio
On Tue, 18 Oct 2011 14:15:13 +0200, Michał Sawicz mic...@sawicz.net wrote: Dnia 2011-10-18, wto o godzinie 14:03 +0200, Rémi Denis-Courmont pisze: If the user has selected I want to record (or stream) my desktop, how does the application get hold of the desktop audio? In other words how should it select a sink monitor source? It as in the application should not, at all. Oh really? The user should select that monitor in his volume-control of choice. So where in pavucontrol do I select the VIDEO source? Duh? Even Skype does that now. The drop-downs in Skype's sound preferences only contain Pulseaudio here. Skype is a voice call and videoconferencing tool. Using the default PulseAudio source makes perfect sense there. First time, it will get the default microphone. Next time, it will get the source that it had the previous time if available. All is good for Skype. If the user selects desktop recording, this does not work. -- Rémi Denis-Courmont http://www.remlab.net/ ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Screen casting with PulseAudio
be good. But I reckon it's not there (yet) which is why I'm asking what's the correct path. It seems the only solution is to list all inputs then :/ (or extend PulseAudio but my free time is not extensible.) -- Rémi Denis-Courmont http://www.remlab.net/ ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Screen casting with PulseAudio
Le mardi 18 octobre 2011 16:35:59 David Henningsson, vous avez écrit : Btw, as for recording microphone, that does seem adequate to me, e g if somebody records things like Now look what happens when I press this button. Fair enough, but a PulseAudio client cannot cleanly ask PulseAudio to mix a microphone and a monitor, or can it? -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Buffering attributes with variable format
Le lundi 10 octobre 2011 18:35:02 Pierre-Louis Bossart, vous avez écrit : Whether passing multiple format infos to negotiate digital passthrough, or setting one of the PA_STREAM_FIX_* flags on a record stream, I'm a bit puzzled how the buffering attributes are supposed to work. Most of the values are expressed in bytes. How should the application negotiate certain timings then? The mapping of bytes to microseconds depends on the bitrate, which is not known to the application until after PulseAudio chooses the exact stream format and returns it. Actually there's no variable format. Yeah? I never said there were formats with variable bit rate. I said I don't know the format, hence the bit rate, until after the buffer attributes have already been transmitted. With the IEC61937 format, the compressed frames are padded with zeroes to reach the same bitrate as 2ch, 16-bit PCM. In short if you have AC3 at 48kHz, PulseAudio will handle 1,536 Mbits/s. You can set the buffering as if it was a PCM stream. I would recommend you set -1 to all the fields and let PulseAudio select the best buffering for low-power. This is only an option if there are no latency constraints. -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Buffering attributes with variable format
Le lundi 10 octobre 2011 21:31:30 Pierre-Louis Bossart, vous avez écrit : I don't have time to waste for threads like these. Oh yeah. Sorry that I spend much of the free time I had in the past few months fixing our code (good), adapting to PulseAudio new requirements (not very good) or working around PulseAudio limitations (bad). But you are right. Intel OTC is surely not paying you to care about mere hobbyists. Let them fuck off. Thanks a lot. -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Buffering attributes with variable format
Le lundi 10 octobre 2011 19:57:03 Arun Raghavan, vous avez écrit : You could pick the most conservative of your formats and then adjust after connecting using pa_stream_set_buffer_attr(). Hmm OK. But what's most conservative here? There is over an order of magnitude between float32 7.1 at 192kHz and G.711. Won't it disturb the precise machinery if you take an extreme only to revert back to saner values? -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] [PATCH 0/1] VLC pass-through to PulseAudio
Hello, Le mardi 27 septembre 2011 20:49:27 Rémi Denis-Courmont, vous avez écrit : The following patch makes VLC negotiates S/PDIF pass-through with PulseAudio for A/52 and DTS audio tracks. This requires PulseAudio client library version 1.0.0 (or later) to compile, and a similarly recent PulseAudio server to actually work. FYI, this was merged with minor changes. S/PDIF passthrough is now also available in released VLC version 1.1.12. That version lacks the infrastructure to cope with format-lost though; it will come in VLC 1.2.0. Regards, -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [RFC] [PATCH 0/2] PulseAudio pass-through VLC support
Hello, This is an hopefully better patch series, based on IRC feedback from Arun Raghavan. Unfortunately, this is still untested, except for the PCM fallback case due to lack of hardware on my side. Timer trigger as suggested by David Henningsson was already pushed to VLC master git as of today. I am still unsure how the tlength buffer attribute should be dealt with when there are more than one negotiated audio format. The following changes since commit 01ec282c28ddf128a4d43d65a1f7d05c408bda4c: Use a timer rather zero padding to trigger the PulseAudio stream (2011-10-03 20:13:37 +0300) are available in the git repository at: git://git.remlab.net/vlc.git spadif Rémi Denis-Courmont (2): PulseAudio: add stream event callback and handle format-lost PulseAudio: negotiate digital pass-through for A/52 and DTS modules/audio_output/pulse.c | 92 +- 1 files changed, 91 insertions(+), 1 deletions(-) -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH 1/2] PulseAudio: add stream event callback and handle format-lost
---
modules/audio_output/pulse.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/modules/audio_output/pulse.c b/modules/audio_output/pulse.c
index c3c0aa0..fc7cdb8 100644
--- a/modules/audio_output/pulse.c
+++ b/modules/audio_output/pulse.c
@@ -355,6 +355,24 @@ static void stream_state_cb(pa_stream *s, void *userdata)
(void) userdata;
}
+static void stream_event_cb(pa_stream *s, const char *name, pa_proplist *pl,
+void *userdata)
+{
+audio_output_t *aout = userdata;
+
+/* FIXME: expose aout_Restart() directly */
+if (!strcmp(name, format-lost)) {
+vlc_value_t dummy = { .i_int = 0 };
+
+msg_Dbg (aout, format lost);
+aout_ChannelsRestart (VLC_OBJECT(aout), audio-device,
+ dummy, dummy, NULL);
+} else
+msg_Warn (aout, unhandled event %s, name);
+(void) s;
+(void) pl;
+}
+
static void stream_moved_cb(pa_stream *s, void *userdata)
{
audio_output_t *aout = userdata;
@@ -791,6 +809,7 @@ static int Open(vlc_object_t *obj)
}
sys-stream = s;
pa_stream_set_state_callback(s, stream_state_cb, NULL);
+pa_stream_set_event_callback(s, stream_event_cb, aout);
pa_stream_set_latency_update_callback(s, stream_latency_cb, aout);
pa_stream_set_moved_callback(s, stream_moved_cb, aout);
pa_stream_set_overflow_callback(s, stream_overflow_cb, aout);
@@ -856,6 +875,7 @@ static void Close (vlc_object_t *obj)
/* Clear all callbacks */
pa_stream_set_state_callback(s, NULL, NULL);
+pa_stream_set_event_callback(s, NULL, NULL);
pa_stream_set_latency_update_callback(s, NULL, NULL);
pa_stream_set_moved_callback(s, NULL, NULL);
pa_stream_set_overflow_callback(s, NULL, NULL);
--
1.7.6.3
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH 2/2] PulseAudio: negotiate digital pass-through for A/52 and DTS
---
modules/audio_output/pulse.c | 72 +-
1 files changed, 71 insertions(+), 1 deletions(-)
diff --git a/modules/audio_output/pulse.c b/modules/audio_output/pulse.c
index fc7cdb8..cf2ed09 100644
--- a/modules/audio_output/pulse.c
+++ b/modules/audio_output/pulse.c
@@ -646,6 +646,9 @@ static int Open(vlc_object_t *obj)
/* Sample format specification */
struct pa_sample_spec ss;
vlc_fourcc_t format = aout-format.i_format;
+#if PA_CHECK_VERSION(1,0,0)
+pa_encoding_t encoding = PA_ENCODING_INVALID;
+#endif
switch(format)
{
@@ -686,6 +689,28 @@ static int Open(vlc_object_t *obj)
case VLC_CODEC_U8:
ss.format = PA_SAMPLE_U8;
break;
+#if PA_CHECK_VERSION(1,0,0)
+case VLC_CODEC_A52:
+format = VLC_CODEC_SPDIFL;
+encoding = PA_ENCODING_AC3_IEC61937;
+ss.format = HAVE_FPU ? PA_SAMPLE_FLOAT32NE : PA_SAMPLE_S16NE;
+break;
+/*case VLC_CODEC_EAC3:
+format = VLC_CODEC_SPDIFL FIXME;
+encoding = PA_ENCODING_EAC3_IEC61937;
+ss.format = HAVE_FPU ? PA_SAMPLE_FLOAT32NE : PA_SAMPLE_S16NE;
+break;
+case VLC_CODEC_MPGA:
+format = VLC_CODEC_SPDIFL FIXME;
+encoding = PA_ENCODING_MPEG_IEC61937;
+ss.format = HAVE_FPU ? PA_SAMPLE_FLOAT32NE : PA_SAMPLE_S16NE;
+break;*/
+case VLC_CODEC_DTS:
+format = VLC_CODEC_SPDIFL;
+encoding = PA_ENCODING_DTS_IEC61937;
+ss.format = HAVE_FPU ? PA_SAMPLE_FLOAT32NE : PA_SAMPLE_S16NE;
+break;
+#endif
default:
if (HAVE_FPU)
{
@@ -800,9 +825,39 @@ static int Open(vlc_object_t *obj)
sys-base_volume = PA_VOLUME_NORM;
pa_cvolume_set(sys-cvolume, ss.channels, PA_VOLUME_NORM);
-vlc_pa_lock();
+#if PA_CHECK_VERSION(1,0,0)
+pa_format_info *formatv[2];
+unsigned formatc = 0;
+
+/* Favor digital pass-through if available*/
+if (encoding != PA_ENCODING_INVALID) {
+formatv[formatc] = pa_format_info_new();
+formatv[formatc]-encoding = encoding;
+pa_format_info_set_rate(formatv[formatc], ss.rate);
+pa_format_info_set_channels(formatv[formatc], ss.channels);
+formatc++;
+}
+
+/* Fallback to PCM */
+formatv[formatc] = pa_format_info_new();
+formatv[formatc]-encoding = PA_ENCODING_PCM;
+pa_format_info_set_sample_format(formatv[formatc], ss.format);
+pa_format_info_set_rate(formatv[formatc], ss.rate);
+pa_format_info_set_channels(formatv[formatc], ss.channels);
+formatc++;
+
/* Create a playback stream */
+pa_stream *s;
+
+vlc_pa_lock();
+s = pa_stream_new_extended(ctx, audio stream, formatv, formatc, NULL);
+
+for (unsigned i = 0; i formatc; i++)
+pa_format_info_free(formatv[i]);
+#else
+vlc_pa_lock();
pa_stream *s = pa_stream_new(ctx, audio stream, ss, map);
+#endif
if (s == NULL) {
vlc_pa_error(obj, stream creation failure, ctx);
goto fail;
@@ -823,6 +878,21 @@ static int Open(vlc_object_t *obj)
goto fail;
}
+#if PA_CHECK_VERSION(1,0,0)
+if (encoding != PA_ENCODING_INVALID) {
+const pa_format_info *info = pa_stream_get_format_info(s);
+
+assert (info != NULL);
+if (pa_format_info_is_pcm (info)) {
+msg_Dbg(aout, digital pass-through not available);
+format = HAVE_FPU ? VLC_CODEC_FL32 : VLC_CODEC_S16N;
+} else {
+msg_Dbg(aout, digital pass-through enabled);
+pa_stream_set_latency_update_callback(s, NULL, NULL);
+}
+}
+#endif
+
const struct pa_buffer_attr *pba = pa_stream_get_buffer_attr(s);
msg_Dbg(aout, using buffer metrics: maxlength=%u, tlength=%u,
prebuf=%u, minreq=%u,
--
1.7.6.3
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Google ChromeOS reinventing the wheel, ignoring PulseAudio
Le mardi 27 septembre 2011 17:27:14 Arun Raghavan, vous avez écrit : Do you have any more details? Seems to be more of a policy daemon than an audio server. Isn't audio policy daemon just a fancier name for (modern) audio server? Does PulseAudio not implement audio policy? Sure, PulseAudio certainly does not police video devices. That's partly done by the X server (XVideo grabs), partly by the window manager, but mostly not done at all. But still... -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [RFC] [PATCH 0/1] VLC pass-through to PulseAudio
Hello all, The following patch makes VLC negotiates S/PDIF pass-through with PulseAudio for A/52 and DTS audio tracks. This requires PulseAudio client library version 1.0.0 (or later) to compile, and a similarly recent PulseAudio server to actually work. I do not have S/PDIF speakers, so I was only able to test that normal PCM playback and PCM fallback work. So the probability that this does not work properly is about 99%. -- The following changes since commit 67889ac99eceb167f4fade5c73a3438ace4925ff: Move character escaping from the model contents, to the output helpers. (2011-09-27 18:07:04 +0300) are available in the git repository at: git://git.remlab.net/vlc-courmisch.git spadif Rémi Denis-Courmont (1): PulseAudio: negotiate digital pass-through for A/52 and DTS modules/audio_output/pulse.c | 73 +- 1 files changed, 72 insertions(+), 1 deletions(-) -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] VLC, PulseAudio and large tlengths
Le samedi 20 août 2011 20:20:27 Tanu Kaskinen, vous avez écrit : Why not? It sounds like you'd want to define underrun differently from what it's currently defined as. An audio underrun is a situation whereby the next sample is not available by the time that it is needed. That is the One And Only definition. To me it seems like your definition is compatible with my definition. An underrun message is sent when there's no audio in the stream buffer when it's needed by the sink. There just happens to be period of time after the underrun when a glitch can still be avoided by rewriting the sink buffer. Sorry... You could maybe argue that an underrun is a general situation whereby the buffer is lower than it should because the fill speed is slower than the consumption speed. But the libpulse API uses the term underflow. A buffer underflow is an _empty_ buffer, not merely a less than optimally filled buffer. Currently an underrun means that there was not enough data in the stream buffer to satisfy the sink's request when it wanted to fill its buffer. I'm not saying that the current definition is the best possible, but I don't see anything obviously wrong in it either. Then I'm sorry for you. Go get yourself an English dictionary. If VLC assumes that an underrun message means silence/glitch, it's a bug in VLC, Are you kidding me? Is this that the level of hypocrisy that I should expect when dealing with PulseAudio? No, I was not kidding. I didn't think I'd be offensive either, but maybe I came across as rude. Sorry about that. If the term underrun causes you to do invalid assumptions about Pulseaudio's internal behavior, then the term may be wrong (which you seem to claim), or the documentation may be lacking. The only way that there could be no glitch is if PulseAudio would do some black magic to extrapolate the missing samples, in the event of an underflow. I don't think this is what happens? Anyway. Ignoring underflows is not really an option. When they do _really_ happen, e.g. due to serious scheduling problems, VLC has to resynchronize the stream somehow. I don't see any solution other than down-sampling or padding, or is there? Now, if we assume there was an underflow, I think it's sane to assume that there will be a glitch. One glitch sounds bad, but it sounds better (IMHO) than both a glitch and then temporary downsampling... That's the rationale. It's also a lot less CPU intensive to not resample. -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] VLC, PulseAudio and large tlengths
Le samedi 20 août 2011 10:33:18 David Henningsson, vous avez écrit : VLC currently assumes that a PulseAudio under-run event implies a silence/glitch. It uses it as an opportunity to resync the audio stream... this is not good if there was no actual under-run :-/ Agreed. PulseAudio should not send the underrun message if there is a possibility that the client can avoid the underrun by sending more data. Fixing that is quite complex though. :-( VLC could ignore underflow events. But I fear this will cause Doppler effect when VLC resorts to resampling to catch up instead. -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] VLC, PulseAudio and large tlengths
Le samedi 20 août 2011 21:46:16 Tanu Kaskinen, vous avez écrit : Anyway. Ignoring underflows is not really an option. When they do _really_ happen, e.g. due to serious scheduling problems, VLC has to resynchronize the stream somehow. I don't see any solution other than down-sampling or padding, or is there? By resynchronizing I guess you mean maintaining A-V sync? Mostly lip sync, yes. (...) I think the idea is that you can at any time query the current playback latency (fixed hardware latency + currently buffered data) and use this information to schedule the video frames. That would arguably be the best way to implement a video file player. But the display vertical refresh is an alternative master clock. In the first case, you may need to drop or duplicate frames. In the second case, you may need to resample the audio signal. Anyway VLC is built with live playback in mind (it started as a DVB-IP receiver afterall). VLC uses to the input signal as the master clock (or the CPU monotonic clock by default). I believe gstreamer uses a similar logic though I have not checked. In fact, that is the only practical option if the receiver does not control the input pace. So the audio can and does drift. This is compensated through resampling. Normally VLC would do it internally. Now the PulseAudio is unique among VLC audio outputs insofar as PulseAudio resamples on VLC behalf. David suggested that a while ago. I'm not sure how downsampling is relevant here. Is the video being synchronized to the wall clock instead of the audio clock and you need to make the audio stream go faster to catch up with the video stream? Currently, VLC tolerates 40 ms advance and 60 ms delay as per EBU Recommendation 37. If a PulseAudio latency update indicates that playback does not fall within that 100 ms sliding window, VLC changes the sample rate to try to restore synchronization without glitch. It is thus essential that the stream gets triggered approximately on time, whether that is initially, upon resuming from pause, or upon recovering from underflow. Otherwise, resampling kicks in and you get to hear Doppler. If that's the case, don't you run into trouble with the wall clock and the audio clock drifting apart (the sound card most likely doesn't run exactly at 48000 Hz even if it claims to do so)? Oh yeah. We do. But that's unavoidable in the general case. -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] VLC, PulseAudio and large tlengths
Hello, Le vendredi 19 août 2011 21:02:59 David Henningsson, vous avez écrit : I've spent most the afternoon trying to figure out why VLC doesn't work well with a large tlengths. I seem to have found suboptimal behaviour on both the PulseAudio and VLC sides. Nice. What bothers me on the PulseAudio side is this call (in alsa-sink.c, mmap_write): pa_sink_render_into_full(u-sink, chunk); For this example, assume tlength is 500 ms and minreq is 50 ms. In adjust latency mode (which I understand is recommended for power efficiency), this is configured to the client's tlength/2 - minreq = 200 ms. The problem here is that if the client is filled up to only e g 130 ms, PulseAudio will take the 130 ms, the client will underrun, and hand out 70 ms of silence. A better behaviour would be to write the 130 ms that are available, and go to sleep until the 130 ms is almost up and see if more data has come in at that time. However, things are probably not as bad as it looks. If a new package comes in from the client in time, I believe PulseAudio would rewind back the 70 ms of silence and write the new data, and no glitch will be heard. So the worst thing is actually the somewhat false alarm sent to the client. VLC currently assumes that a PulseAudio under-run event implies a silence/glitch. It uses it as an opportunity to resync the audio stream... this is not good if there was no actual under-run :-/ However messing with PulseAudio's buffering mechanisms isn't giving me warm and fuzzy feelings, at least not right before the 1.0 release :-D So over to the VLC side. I started off with the current git head of VLC. For the synchronisation, I believe the correct way is to do something like: 1) when the first packet arrives, notice its timestamp (pts), and set a system timer to trigger at that point in time (i e trigger in i-pts - mdate() usecs) Yeah. That would certainly be better than the current zero padding of the stream, especially when resuming from pause (i.e. PulseAudio uncorking). But but, VLC does not have a mainloop. A timer is going to need a dedicated thread. Or maybe libpulse can accept user timers in its threaded mainloop? 2) the callback from the system timer would then uncork/trigger the stream. At that point, PulseAudio's buffer has been filled up by all the other calls to Play that happened in between. I did a quick hack myself: I didn't know how to do system timers in VLC so I set it to check at every call to Play, if it was yet time to start the stream. (And commented out the call to stream_resync.) That gave good synchronisation as well as I could see (being layman on observing synchronisation issues). vlc_timer_*() functions. But I'd rather use the Pulse mainloop if possible. For the buffering attributes, I tried setting tlength to 500 ms (note: AOUT_MAX_PREPARE_TIME is actually 2000 ms, not 500 ms as I originally thought). Given an initial filled buffer as suggested above, that did not underrun. That was with playing back a local video file. I set minreq to AOUT_MIN_PREPARE_TIME (40 ms), which is mostly taken out of the air. However, given the reasoning above, if you want to be certain to avoid the false underrun alarms as outlined in the PulseAudio section, I believe a minreq of AOUT_MIN_PREPARE_TIME and tlength of AOUT_MIN_PREPARE_TIME * 4 = 160 ms should be a relatively safe setting. In my experience, larger tlength caused more underruns. But maybe that's because VLC is more likely to be continuously late? Also remember to set the PA_STREAM_ADJUST_LATENCY flag. It's not clear to me what this actually will do. Hopefully this gives a little insight in the current problems with VLC and PulseAudio! -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] bools and bit-fields
Le jeudi 18 août 2011 17:53:43 Arun Raghavan, vous avez écrit : The condition in the if statement may evaluate to false if pa_bool_t is typedef'ed to a signed type (it definitely is if you don't have stdbool.h, not sure if _Bool is a signed type or not). The ISO C standard requires that _Bool bit fields with non-zero width can store _and_ *compare* to 0 and 1. This happens because it's a single bit field and thus when the msb (the only bit) is set to 1 it is interpreted as -1. Right. So pa_bool_t should be typedef'd to 'unsigned' rather than 'int' wherever HAVE_STD_BOOL is not defined. Then again, stdbool.h is a non-optional part of the C standard. Defining your own boolean type feels very 90's (and indeed error-prone). -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] libpulse deadlock
Hello,
I might have missed something obvious but there seems to be a race condition
resulting in a deadlock in libpulse 0.9.22 (Debian).
I have stream with prebuf disabled (zero). When the Close() function below
gets called, if the stream is _not_ corked, the pa_stream_drain() callback
never gets called, so pa_threaded_mainloop_wait() never returns and the whole
process jams.
This seems timing dependent: if I put a gdb breakpoint on
pa_operation_get_state() then continue, the callback does get called and the
process does not get stuck on the condition variable. There is also no problem
if the stream is corked, in which case we use pa_stream_flush() instead of
pa_stream_drain().
The code follows:
static void stream_success_cb(pa_stream *s, int success, void *userdata)
{
pa_threaded_mainloop *mainloop = userdata;
fprintf(stderr, DONE: %d\n, success);
pa_threaded_mainloop_signal(mainloop, 0);
(void) s;
(void) success;
}
/* ... */
static void Close(vlc_object_t *obj)
{
aout_instance_t *aout = (aout_instance_t *)obj;
aout_sys_t *sys = aout-output.p_sys;
pa_threaded_mainloop *mainloop = sys-mainloop;
pa_context *ctx = sys-context;
pa_stream *s = sys-stream;
/* ... */
pa_threaded_mainloop_lock(mainloop);
if (s != NULL) {
pa_operation *op;
if (pa_stream_is_corked(s) 0)
/* Stream paused: discard all buffers */
op = pa_stream_flush(s, stream_success_cb, mainloop);
else
/* Stream playing: wait until buffers are played */
op = pa_stream_drain(s, stream_success_cb, mainloop);
if (likely(op != NULL)) {
while (pa_operation_get_state(op) == PA_OPERATION_RUNNING) {
fprintf(stderr, waiting\n);
pa_threaded_mainloop_wait(mainloop);
}
pa_operation_unref(op);
}
pa_stream_disconnect(s);
pa_stream_unref(s);
}
if (ctx != NULL)
pa_context_unref(ctx);
pa_threaded_mainloop_unlock(mainloop);
pa_threaded_mainloop_free(mainloop);
free(sys);
}
--
Rémi Denis-Courmont
http://www.remlab.net/
http://fi.linkedin.com/in/remidenis
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
