[LAU] Connect pipewire to running JACK server

[Yann Collette]

Le 02/02/2022 à 23:04, David Kastrup a écrit :
> Yann Collette <ycollette.nospam at free.fr> writes:
>
>> Le 28/01/2022 à 16:40, ycollette.nospam at free.fr a écrit :
>>> Nice, thanks for the hint. I will do some tests next week.
>>>
>>> ----- Mail original -----
>>> De: "David Kastrup" <dak at gnu.org>
>>> À: "ycollette nospam" <ycollette.nospam at free.fr>
>>> Cc: "Tim" <termtech at rogers.com>, linux-audio-user at lists.linuxaudio.org
>>> Envoyé: Vendredi 28 Janvier 2022 16:37:52
>>> Objet: Re: [LAU] Connect pipewire to running JACK server
>>>
>>> ycollette.nospam at free.fr writes:
>>>
>>>> Can somebody share pipewire configuration files for low latency audio with pw-jack ?
>>>> I am still struggling but maybe this is due to the audio USB interface
>>>> I've got: FocusRite 18i8.
>>> It's maybe not overly relevant for your case but I've had significantly
>>> different experiences with, say, the Mackie Onyx Satellite and the ALSA
>>> drivers by picking period sizes of 128 (which does not work without
>>> periodic dropouts not marked as Xruns) and even something as low as 24
>>> samples: apparently at least at 48kHz or 96kHz it is crucial to have the
>>> period size divisable by 3.  And if it is, very low latencies are
>>> possible while if it isn't, you get garbage.
>>>
>> I just tested the "multiple of 3" rule and effectively, it worked.
>>
>> With a buffer size of 256, I've got garbage and with the buffer of
>> size 128 it's fine.
> 192? 96?
Just tried 128. I will try these 2 this week-end.
>
>> How did you find this rule ? Trial and errors ?
> Yes and no.  Some Windows ASIO drivers refused to do anything but that
> for some Behringer USB card and worked with stuff as ridiculously low as
> 24.  And if you try converting period sizes to millisecs, you need that
> factor of 3.
>
> The Opus Codec has as smallest standard size 120 samples @48kHz
> (2.5msec) .  Stuff like that.  48kHz needs that factor of 3 to map
> nicely to millisecs.
>
> It doesn't make a superb amount of sense to me I'll readily admit.
> Maybe the actual rule is "avoid powers of 2" for some drivers and/or
> hardware, and 3x2^n is about as far from a power of 2 as you can get.
>
Ok, thanks a lot for this explanation :)