[L2Ork-dev] Current HEAD of Purr Data is broken

Jonathan Wilkes jon.w.wilkes at gmail.com
Sat Jul 4 09:18:17 EDT 2020


On Sat, Jul 4, 2020 at 8:41 AM Albert Graef <aggraef at gmail.com> wrote:
>
> On Sat, Jul 4, 2020 at 4:20 AM Jonathan Wilkes <jon.w.wilkes at gmail.com> wrote:
>>
>> Not much compares to the Asus C201.
>
>
> That looks like a really nice machine. Apparently, they're out of stock, but of course there are newer models available.
>
> Yeah, the Pinebook Pro looks a bit experimental and flimsy to me, so I'm really tempted to buy one of these Chromebooks instead, if Purr Data runs on them. :) I guess that I'll have to install Linux on the device first, though, to get Purr Data to run on it?

I should have mentioned the one subsystem which was flaky on that
machine. Can you guess what it is? :)

https://www.chromium.org/chromium-os/chromiumos-design-docs/cras-chromeos-audio-server

"The basic design combines the timer-driven wakeup scheme of
pulseaudio with the synchronous audio callbacks of JACK. This
synchronous callback eliminates local buffering of data in the server,
allowing the server to wake up less for a given latency. The server
wakes up when a timer fires, sometime before there is an ALSA
over/underrun and calls back to Chromium to get/put audio data. This
minimizes latency as the only additional latency needed is that to
exchange IPC messages between the server and client. Because ALSA
wakeups aren’t used, on some devices the minimal latency will be lower
than without the server; there is no need to wake up at an ALSA period
boundary. The timer can be armed to wake up when there are an
arbitrary number of samples left in the hardware buffer. ALSA will
always be configured with the largest possible buffer size, yet only
some fraction of that will be used at any given time."

That's quite a claim about "minimal latency." Even Jack claims only
that Jack + ALSA doesn't add any latency, not that it can improve the
situation (even though users apparently think that). I've got a
budding theory that any claim about "unprefixed" latency in an
audio-related system will be made false if you prefix the words "round
trip" before it.

I haven't tested that theory with cras, but AFAICT it was the only
subsystem that would get in a bad enough state to require a reboot of
the Chromebook.

-Jonathan

>
> Thanks,
> Albert
>


More information about the L2Ork-dev mailing list