[L2Ork-dev] issues on rasbian 9/10

Fri Apr 9 19:11:02 EDT 2021

On Fri, Apr 9, 2021 at 4:06 PM Jonathan Wilkes <jon.w.wilkes at gmail.com>
wrote:

> What happens when you run with relatime priority?
>

We already do that by default on Linux. At least that's what I see in the
code, and what those "priority x scheduling enabled" messages in the
console indicate. Otherwise, real-time audio just doesn't work at all,
you'll get xruns galore even on much more powerful systems than the Pi3/4.

As I said, all this works fine on the Pi even with the most basic USB audio
interface, both with Jack and without, so it can't be the scheduling.

Albert

> -Jonathan
>
> On Fri, Apr 9, 2021 at 5:09 AM Albert Graef <aggraef at gmail.com> wrote:
>
>> Here's the Raspbian 10 deb of my special build in case you want to give
>> this a try yourself. (I'm rolling back the package on the OBS preview
>> channel now, so I uploaded a copy of this package to my Google Drive.)
>>
>>
>>  purr-data_2.16.0+git4809+6d74b30a-1_armhf.deb
>> <https://drive.google.com/file/d/1Egjb2k_Q3Svbuv1d9irjv_-h-zv-FOKR/view?usp=drive_web>
>>
>> On Fri, Apr 9, 2021 at 11:00 AM Albert Graef <aggraef at gmail.com> wrote:
>>
>>> Ok, I gave that a try now, but unfortunately it didn't help much. :( The
>>> high-pitched noise is gone, so that's an improvement. But the ALSA backend
>>> still only gets a bunch of xruns and then gives up after printing "restart
>>> alsa output; alsa xrun recovery apparently failed" a couple of times in the
>>> terminal, logging "error: audio I/O stuck... closing audio" in the Pd
>>> console.
>>>
>>> One thing I noticed in htop is that the nw.js gui spawns quite a few
>>> threads all running at a nice level of -7, while the engine itself runs at
>>> -9. In vanilla you just get the wish gui (a single thread) running at 20,
>>> while the engine runs at -7. So there are some clear differences between
>>> purr-data and vanilla even if the ALSA backend is exactly the same (in that
>>> special build of purr-data I just did). I'm not sure why we run the GUI at
>>> such a high priority; maybe that's part of the problem. Jonathan might be
>>> able to shed some light on this.
>>>
>>> As I said before, all these issues go away if you just use an external
>>> sound card, so the dsp *is* part of the equation here. Such a device will
>>> also work with Jack just fine. Even one of those really cheap and small USB
>>> audio adapters that you can get on Amazon for a couple of bucks will do the
>>> trick (I have the one from UGREEN, but the one from Sabrent[1] is also
>>> available on amazon.com and should do the job as well).
>>>
>>> [1] https://www.amazon.com/-/de/dp/B00IRVQ0F8
>>>
>>> Sorry Marten, I wished I had better news for you. It would still be nice
>>> if you could submit a full bug report on this, so that we can document what
>>> we know about this bug and hopefully fix it some time. But for the time
>>> being my suggestion for you would be to just get one of those little USB
>>> audio thingies and call it a day. ;-)
>>>
>>> Best,
>>> Albert
>>>
>>>
>>> On Fri, Apr 9, 2021 at 2:29 AM Albert Graef <aggraef at gmail.com> wrote:
>>>
>>>> Just a quick followup: Comparing the source of our s_audio_alsa.c with
>>>> that of vanilla I do see some substantial differences. In particular, it
>>>> seems that we never backported two of Miller's commits from way back then,
>>>> https://github.com/agraef/pure-data/commit/75819aad and
>>>> https://github.com/agraef/pure-data/commit/de2ba0f6. In particular,
>>>> the former has an entire chunk of sw parameter initializations which is
>>>> completely missing in our code.
>>>>
>>>> What I can do as a quick check is to pull the latest s_audio_alsa.c
>>>> from vanilla into my testing branch and do a test build on my OBS preview
>>>> channel so that we can try it out on the Pi. That way we'll lose Sam
>>>> Thurston's recent MR concerning the error checking code in the module, but
>>>> we can always pull that back in again later if needed (vanilla also has
>>>> some changes there, so Sam's fixes might not be needed any more).
>>>>
>>>> Stay tuned,
>>>> Albert
>>>>
>>>>
>>>>
>>>> On Fri, Apr 9, 2021 at 1:42 AM Albert Graef <aggraef at gmail.com> wrote:
>>>>
>>>>> Hi Marten,
>>>>>
>>>>> I have exactly the same issue on my Raspberry Pi4. Purr works mostly
>>>>> fine even with a cheap USB audio dongle, but not with the built-in
>>>>> soundcard of the Pi. Pd 0.49.0 straight from the Buster repo works fine. So
>>>>> clearly there's a bug lurking in our ALSA support somewhere or we're
>>>>> missing some bit in the backend which makes this work in vanilla.
>>>>>
>>>>> This was discussed on the ml before, and IIRC we've blamed it all on
>>>>> the poor dsp of the Pi. ;-) But this can't be true if it works just fine in
>>>>> vanilla. So we should try again to track this down. It would help if you
>>>>> could submit a bug report at
>>>>> https://git.purrdata.net/jwilkes/purr-data/-/issues, then I'll look
>>>>> into it asap.
>>>>>
>>>>> Thanks,
>>>>> Albert
>>>>>
>>>>>
>>>>> On Thu, Apr 8, 2021 at 4:58 PM Marten Seedorf <
>>>>> marten.seedorf at mailbox.org> wrote:
>>>>>
>>>>>> Hey everyone,
>>>>>>
>>>>>> working on a sound installation with purr-data on the raspberry pi I
>>>>>> encountered some issues that might be worth mentioning.
>>>>>>
>>>>>> I installed the recent rasperry pi os (~ raspbian 10 buster) on a
>>>>>> raspberry pi 3B and installed purr-data from Albert Gräfs repositories on
>>>>>> opensuse.org. The installation went smoothly, but the audio engine
>>>>>> (alsa) didn't work. All I got was a high pitched, distorted noise. I tried
>>>>>> to use jack, but strangely it wasn't able to communicate with the audio
>>>>>> hardware via alsa as well. So it seems that the issue is rather in the OS
>>>>>> than in Purr Data. But: PD Vanilla is working perfectly fine (directly with
>>>>>> alsa, without jack).
>>>>>>
>>>>>> I went back to Raspbian 9 Stretch and installed Purr-Data from the
>>>>>> latest pre-build deb.-package I could find (2.10.1). That worked great.
>>>>>>
>>>>>> I became curious and installed Purr-Data on stretch from the
>>>>>> opensuse-repositories (Raspbian 9) and encountered the same issues as in
>>>>>> buster.
>>>>>>
>>>>>> So in the end, I found a solution that works for me. Still I figure
>>>>>> there could be something wrong with the repositories.
>>>>>>
>>>>>> Best,
>>>>>> Marten
>>>>>> _______________________________________________
>>>>>> L2Ork-dev mailing list
>>>>>> L2Ork-dev at disis.music.vt.edu
>>>>>> https://disis.music.vt.edu/listinfo/l2ork-dev
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Dr. Albert Gr"af
>>>>> Computer Music Research Group, JGU Mainz, Germany
>>>>> Email: aggraef at gmail.com, web: https://agraef.github.io/
>>>>>
>>>>
>>>>
>>>> --
>>>> Dr. Albert Gr"af
>>>> Computer Music Research Group, JGU Mainz, Germany
>>>> Email: aggraef at gmail.com, web: https://agraef.github.io/
>>>>
>>>
>>>
>>> --
>>> Dr. Albert Gr"af
>>> Computer Music Research Group, JGU Mainz, Germany
>>> Email: aggraef at gmail.com, web: https://agraef.github.io/
>>>
>>
>>
>> --
>> Dr. Albert Gr"af
>> Computer Music Research Group, JGU Mainz, Germany
>> Email: aggraef at gmail.com, web: https://agraef.github.io/
>> _______________________________________________
>> L2Ork-dev mailing list
>> L2Ork-dev at disis.music.vt.edu
>> https://disis.music.vt.edu/listinfo/l2ork-dev
>
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> https://disis.music.vt.edu/listinfo/l2ork-dev

-- 
Dr. Albert Gr"af
Computer Music Research Group, JGU Mainz, Germany
Email: aggraef at gmail.com, web: https://agraef.github.io/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20210410/24b57265/attachment-0001.html>