Re: Network audio stuttering?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Could you please open a bug for this?

On Thu, Dec 27, 2018, 12:03 PM Alexander E. Patrakov <patrakov@xxxxxxxxx> wrote:
Russell Treleaven <rtreleaven@xxxxxxxxxxxx>:
>
> Is there an open bug for this?

No.

>
> On Wed, Dec 26, 2018, 6:41 PM Alexander E. Patrakov <patrakov@xxxxxxxxx> wrote:
>>
>> David Davidović <david@xxxxxxxxxxxx>:
>> >
>> > Hi,
>> >
>> > I'm running a system-wide PulseAudio instance on a headless box connected to my speaker system. The sink is broadcast via Zeroconf and I use it to play music and movies via WiFi from my laptop. The headless box is connected to the WiFi router via a wired connection.
>> >
>> > Unfortunately, every couple of minutes or so, the sound stutters for a short time, then returns to normal.
>> >
>> > Does anyone have any suggestions as to how to debug the source of these issues? My best bet is WiFi latency. I tried increasing the buffer size (via default-fragments and default-fragment-size-msec) on both the client and server machine but I haven't seen any considerable improvement. The actual network packets seem to always be around 1.5K in size, which would be around 4ms of uncompressed sound with 32-bit stereo samples at 44.1kHz, and that's without any overhead. If my calculation is true, this would explain the stuttering, as the network latency towards the machine is at a baseline of ~2ms but can spike sometimes due to nature of WiFi.
>> >
>>
>> Packets are sent in advance, and WiFi cannot allow for bigger packets anyway.
>>
>> > I'd be happy if there was a way to e.g. tell the native-protocol-tcp module to buffer more of the audio and play it, as I don't mind the increased latency; I just want to get rid of the stuttering and all applications I use manage PulseAudio latency compensation quite well.
>>
>> You can't. It's the media player application who requests buffering
>> and specifies the latency. However, if pavucontrol is running, the
>> latency is capped to something like 20 ms, due to the misguided design
>> decision that monitor sinks should monitor what is written right now
>> (not what is playing right now).
>>
>> What would help is a "pactl list sinks" on both ends while music is
>> playing and pavucontrol is not running.
>>
>> > Has anyone else had this issue and resolved it?
>>
>> Yes, by closing pavucontrol.
>>
>> --
>> Alexander E. Patrakov
>> _______________________________________________
>> pulseaudio-discuss mailing list
>> pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx
>> https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
>
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx
> https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss



--
Alexander E. Patrakov
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux