[Vm-dev] re: Mac OS Cocoa MIDI Plugin

[Eliot Miranda]

Hi Craig,

> On May 20, 2016, at 4:02 AM, Craig Latta <craig at blackpagedigital.com> wrote:
> 
> 
> 
> Hi Eliot--
> 
>> First, Cog on Linux in 2010 had to use the itimer heartbeat because
>> pthreads only supported one priority, and so the heartbeat couldn't
>> be a thread. The itimer heartbeat works by delivering signals, and
>> ALSA didn't cope with interrupted system calls.  Second, the X11 GUI
>> and socket i/o depend on delivering SIGIO and ALSA interfered with
>> signal delivery.  When ALSA loaded it installed its own SIGIO handler
>> but didn't check for any previously installed handler and so broke
>> the system.
>> 
>> To fix these two problems I had to maintain my own corrected version
>> of the ALSA code, we were under time pressure and this was quicker
>> than trying to engage the ALSA author(s) to correct the code.
> 
>     Aha, I'm curious to know if your signal fix involved a separate
> host process for ALSA, and/or the SIGRTMIN signals, as mentioned in [1].
> I guess I'll find out soon enough. :)

No. Simply being courteous enough to remember the previous SIGIO handler when the revised ALSA code installed its own, calling the previous handler from the revised ALSA code's SIGIO handler, and reinstalling the previous handler when ALSA is shutdown.  You know, simply following the design of UNIX signals.  

It boggles the mind that something as central as sound code is written by people who evidently have no clue as to how to write UNIX code that uses signals.


The other fixes are to check for EINTR after reads and writes and retry if so.

>> So if ALSA is the only game in town I guess we must get the code
>> fixed.  How is ALSA maintained and by whom?
> 
>     The project hosts a git repository[2]. The core team is listed at [3].
> 
>> Is the code still broken as described above?
> 
>     I suspect so; do you have a minimal regression test I can build and
> run?

The test is to start the image, play a sound, and then unload sound.  The gui used to stop responding to mouse clicks :-(

> 
>>> I found an enlightening and sad summary of the Linux audio
>>> processing architecture[4] which, although written in 2010, seems
>>> to jibe with the current Wikipedia pages for ALSA[5],
>>> PulseAudio[6], JACK[7] (another sound server), and OSS[8], and with
>>> a similarly sad Linux MIDI summary[9].
>> 
>> I'll try and find time to read this.  Care to summarize?
> 
>     Oh, just that there are far too many pieces, with feature sets that
> overlap and build on each other in ever stranger ways over time. It's
> easy to think that one piece is "standard" for a particular role, when
> it actually does something very different. But at least there are
> reasonable overviews now.
> 
>     For Linux Squeak MIDI, the upshot is that we want to play nicely
> with ALSA, and PortMIDI is a good way to do that. More broadly, using
> the PortMedia libraries/APIs would make Squeak audio and MIDI much more
> pleasant on Linux, Windows, and Mac OS. Indeed, let's start by getting
> your ALSA bug confirmed for 2016, then probably get your fix integrated.

Sounds like a plan.

>     thanks again,
> 
> -C
> 
> [1] https://tinyurl.com/z2o58km (linuxquestions.org)
> [2] http://www.alsa-project.org/main/index.php/GIT_Server
> [3] http://www.alsa-project.org/main/index.php/Alsa_Team
> 
> [4] http://tuxradar.com/content/how-it-works-linux-audio-explained
> [5] https://en.wikipedia.org/wiki/Advanced_Linux_Sound_Architecture
> [6] https://en.wikipedia.org/wiki/PulseAudio
> [7] https://en.wikipedia.org/wiki/JACK_Audio_Connection_Kit
> [8] https://en.wikipedia.org/wiki/Open_Sound_System
> [9] http://www.tedfelix.com/linux/linux-midi.html
> 
> --
> Craig Latta
> Black Page Digital
> Amsterdam
> craig at blackpagedigital.com
> +31   6 2757 7177 (SMS ok)
> + 1 415  287 3547 (no SMS)
>