Re: [pulseaudio-discuss] [PATCH] core-util: correct error in set_nonblock()
On Sun, 2018-02-11 at 20:12 +0100, Georg Chini wrote:
> set_nonblock() will always set the file descriptor to non-blocking,
> regardless of the nonblock argument.
>
> This patch fixes the issue by passing the correct argument to the
> fcntl() call. The bug had no impact because there is only one caller
> of pa_make_fd_block() in poll-win32.c
> ---
> src/pulsecore/core-util.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/pulsecore/core-util.c b/src/pulsecore/core-util.c
> index 64e9f217..7f627539 100644
> --- a/src/pulsecore/core-util.c
> +++ b/src/pulsecore/core-util.c
> @@ -202,7 +202,7 @@ static void set_nonblock(int fd, bool nonblock) {
> nv = v & ~O_NONBLOCK;
>
> if (v != nv)
> -pa_assert_se(fcntl(fd, F_SETFL, v|O_NONBLOCK) >= 0);
> +pa_assert_se(fcntl(fd, F_SETFL, nv) >= 0);
>
> #elif defined(OS_IS_WIN32)
> u_long arg;
Looks good to me.
--
Tanu
https://liberapay.com/tanuk
https://www.patreon.com/tanuk
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] Freezing master
Hello, According to the usual release schedule, master should have been frozen already in December, but I've been postponing that (for no good reason). Now finally, if there are no objections, I declare master frozen so that we can soon release 12.0. There won't be a release candidate published immediately, because we have a release blocker bug open[1], but I'm working on a fix and patches should appear soon on the list. I'd also like to have the "[PATCH v2 0/3] Fix Intel HDMI LPE problems" patch set included in 12.0, even though it doesn't fix any release blockers. We have other fixes in master for the HDMI LPE problems, but those are useless without the jack detection fixes. As usual, patches that are reviewed and accepted during the freeze but aren't to be included the 12.0 release will be put in the "next" branch, and once the release is out, the patches in the "next" branch will be added to the "master" branch. The release notes are mostly done already: https://www.freedesktop.org/wiki/Software/PulseAudio/Notes/12.0/ [1] https://bugs.freedesktop.org/show_bug.cgi?id=104761 -- Tanu https://liberapay.com/tanuk https://www.patreon.com/tanuk ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] Odd app behavior with PULSE_PROP="filter.want=echo-cancel"
When I start Zoiper with PULSE_PROP="filter.want=echo-cancel", it demonstrates some odd behavior. It ends up creating many Echo-Cancel Sink and Source streams, and I am unable to select my USB headset as the source of any of them. I think, based on the discussion around a recent crasher bug I reported, Zoiper is trying to be too clever, without being clever enough, and is actually trying to open up various streams to all of the Pulse Input and Output devices. Is this just a Zoiper issue, or is there something I can do on the Pulse side to solve this? I think one option is load the echo-cancellation module once in /etc/pulse/default.pa and then use the volume control to manually hook up Zoiper to that module. Regards, Raman ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v2] pipe-source: suspend source when no writers connected to fifo
On Sat, 2018-02-10 at 23:08 +0100, Georg Chini wrote: > On 10.02.2018 23:04, Raman Shishniou wrote: > > On 02/11/2018 12:43 AM, Georg Chini wrote: > > > On 10.02.2018 22:25, Raman Shuishniou wrote: > > > > 10.02.2018 23:59, Georg Chini пишет: > > > > > On 08.02.2018 17:58, Raman Shyshniou wrote: > > > > > > Make pipe-source suspended if all writers closed fifo. > > > > > > Source will be automatically unsuspended if any data will > > > > > > be written to pipe and suspended again when last writer > > > > > > closed fifo. > > > > > > --- > > > > > >src/modules/module-pipe-source.c | 114 > > > > > > +-- > > > > > >1 file changed, 109 insertions(+), 5 deletions(-) > > > > > > > > > > > > > > > > What is the motivation/use case for the patch? Normally, if there > > > > > are no writers, the source should deliver silence like any other > > > > > source without input signal. > > > > > > > > pipe-source module can't generate silence if no writers connected > > > > because it has no clock. Aactually incoming data has some clock, but > > > > not pipe-source itself. Use the system clock to generate silence > > > > is a bad idea because it may differ from incoming data clock. > > > > > > Take a look at the recent patches for pipe-sink that introduced using > > > system-clock timing. I guess something similar should be possible > > > for the pipe-source. Why would it be a problem, if the timing of the > > > silence is slightly different from that of the writer? Different writers > > > may have different timing anyway, so if one writer disconnects > > > and another connects, timing may change. > > > module-loopback is able to deal with sample rate changes on the > > > input side and will adapt the sample rate of the output side so that > > > it matches the incoming rate to keep a constant latency. > > > > > > > I seen the last patches for pipe-sink module. I think there is no > > reason to generate silence in pipe-source module with system clock. > > The source outputs will do read zeros (resample, convert) - just a > > waste of cpu time. > > > > I see your point. The reason for generating silence would > be to have consistent behavior for all sources. I'll ask Tanu > for his opinion. My opinion: it would be nice to generate silence by default if someone is willing to implement that, but suspending is better than the current behaviour, if the current behaviour is to have the source state as RUNNING while not producing any data. -- Tanu https://liberapay.com/tanuk https://www.patreon.com/tanuk ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Fwd: Adding support for CMEDIA USB2.0 High-Speed True HD Audio
On Fri, 2018-02-09 at 09:30 +0100, Jean-Philippe Guillemin wrote: > Hi, > > No reply from alsa-devel :( > > Thanks for your help > > Also attached the files to fix profile in pulse. > > I have made a lot of tests on my side at alsa level, but the only thing > that fix the iec958 aliasing problem is to tweak alsa.conf, and then pulse > doesn't see analog output devices... > > IMHO : fixing on pulse side is the way to go ;) I applied the PulseAudio configuration changes now. Thanks for your contribution! -- Tanu https://liberapay.com/tanuk https://www.patreon.com/tanuk ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v2 2/3] alsa-mixer: autodetect the HDMI jack PCM device
On Sun, 8 Oct 2017, at 10:18 PM, Tanu Kaskinen wrote:
> This removes the need to hardcode the PCM device index in the HDMI jack
> names. The hardcoded values don't work with the Intel HDMI LPE driver.
>
> BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=100488
> ---
> src/modules/alsa/alsa-mixer.c | 53
> --
> src/modules/alsa/alsa-mixer.h | 4 +-
> src/modules/alsa/alsa-sink.c | 2 +-
> src/modules/alsa/alsa-source.c | 2 +-
> .../alsa/mixer/paths/analog-output.conf.common | 4 ++
> src/modules/alsa/mixer/paths/hdmi-output-0.conf| 3 +-
> src/modules/alsa/mixer/paths/hdmi-output-1.conf| 3 +-
> src/modules/alsa/mixer/paths/hdmi-output-2.conf| 3 +-
> src/modules/alsa/mixer/paths/hdmi-output-3.conf| 3 +-
> src/modules/alsa/mixer/paths/hdmi-output-4.conf| 3 +-
> src/modules/alsa/mixer/paths/hdmi-output-5.conf| 3 +-
> src/modules/alsa/mixer/paths/hdmi-output-6.conf| 3 +-
> src/modules/alsa/mixer/paths/hdmi-output-7.conf| 3 +-
> 13 files changed, 73 insertions(+), 16 deletions(-)
>
> diff --git a/src/modules/alsa/alsa-mixer.c b/src/modules/alsa/alsa-
> mixer.c
> index 02ab4a611..eaee7ea0a 100644
> --- a/src/modules/alsa/alsa-mixer.c
> +++ b/src/modules/alsa/alsa-mixer.c
> @@ -1812,12 +1812,31 @@ static int element_probe(pa_alsa_element *e,
> snd_mixer_t *m) {
> return 0;
> }
>
> -static int jack_probe(pa_alsa_jack *j, snd_mixer_t *m) {
> +static int jack_probe(pa_alsa_jack *j, pa_alsa_mapping *mapping,
> snd_mixer_t *m) {
> bool has_control;
>
> pa_assert(j);
> pa_assert(j->path);
>
> +if (j->append_pcm_to_name) {
> +char *new_name;
> +
> +if (!mapping) {
> +/* This could also be an assertion, because this should
> never
> + * happen. At the time of writing, mapping can only be NULL
> when
> + * module-alsa-sink/source synthesizes a path, and those
> + * synthesized paths never have any jacks, so jack_probe()
> should
> + * never be called with a NULL mapping. */
> +pa_log("Jack %s: append_pcm_to_name is set, but mapping is
> NULL. Can't use this jack.", j->name);
> +return -1;
> +}
> +
> +new_name = pa_sprintf_malloc("%s,pcm=%i Jack", j->name,
> mapping->hw_device_index);
> +pa_xfree(j->alsa_name);
> +j->alsa_name = new_name;
> +j->append_pcm_to_name = false;
Series looks good to me. Just one question -- why do we reset
append_pcm_to_name here? Presumably because jack_probe() is called multiple
times on the jack? Or are you being defensive here?
Cheers,
Arun
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
