Mac OS Cocoa MIDI Plugin

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Mac OS Cocoa MIDI Plugin

Eliot Miranda-2
 
Hi All,

    recently the Cog VM on Mac OS X moved to Cocoa, the Objective-C API for the platform, leaving behind the old Carbon C API.  There is some backward compatibility support but it is gradually being deprecated by Apple.  One victim is the MIDIPlugin which was written against a ComponentManager API that, while Apple docs say is only deprecated, has actually disappeared.  Consequently the MIDIPlugin support (see http://www.squeakvm.org/svn/squeak/branches/Cog/platforms/iOS/plugins/MIDIPlugin) needs completely rewriting to use Cocoa APIs.  I've recently changed the build so that the MIDIPlgin is built externally, which will make it easier to work on; one doesn't need to build the entire VM, only the plugin.  I'm looking for volunteers who
a) love music/know MIDI
b) are happy programming at the Objective-C level using command-line builds and perhaps Xcode, but more immediately lldb for debugging.

If interested, reply to vm-dev and we can continue discussions there; there are folks that can help with Mac OS support, but no one I know of that has time to write this rather important plugin for multi-media.  It would be a great shame to lose MIDI on Mac.

______,,,^..^,,,______
AdvThanksance, Eliot
Reply | Threaded
Open this post in threaded view
|

re: Mac OS Cocoa MIDI Plugin

Craig Latta
 

Hi Eliot--

> recently the Cog VM on Mac OS X moved to Cocoa, the Objective-C API
> for the platform, leaving behind the old Carbon C API.  There is some
> backward compatibility support but it is gradually being deprecated by
> Apple.  One victim is the MIDIPlugin which was written against a
> ComponentManager API that, while Apple docs say is only deprecated,
> has actually disappeared.  Consequently the MIDIPlugin support
> (see http://www.squeakvm.org/svn/squeak/branches/Cog/platforms
> /iOS/plugins/MIDIPlugin) needs completely rewriting to use Cocoa
> APIs.  I've recently changed the build so that the MIDIPlgin is built
> externally, which will make it easier to work on; one doesn't need to
> build the entire VM, only the plugin.  I'm looking for volunteers who
> a) love music/know MIDI
> b) are happy programming at the Objective-C level using command-line
> builds and perhaps Xcode, but more immediately lldb for debugging.
>
> If interested, reply to vm-dev and we can continue discussions there;
> there are folks that can help with Mac OS support, but no one I know
> of that has time to write this rather important plugin for multi-
> media.  It would be a great shame to lose MIDI on Mac.

     Perhaps this is an opportunity to reduce the platform code fanout a
bit. I've had good results with Squeak MIDI before on Mac, Windows, and
Linux, by making a VM plugin from the platform-independent PortMedia
libraries (PortAudio and PortMidi), at [1]. Perhaps it would make sense
to use PortMedia in combination with FFI/Alien these days.


-C

[1] http://portmedia.sourceforge.net

--
Craig Latta
Black Page Digital
Amsterdam
[hidden email]
+31   6 2757 7177 (SMS ok)
+ 1 415  287 3547 (no SMS)



Reply | Threaded
Open this post in threaded view
|

Re: Mac OS Cocoa MIDI Plugin

Bert Freudenberg
 

> On 12.05.2016, at 15:22, Craig Latta <[hidden email]> wrote:
>
>
>
> Hi Eliot--
>
>> recently the Cog VM on Mac OS X moved to Cocoa, the Objective-C API
>> for the platform, leaving behind the old Carbon C API.  There is some
>> backward compatibility support but it is gradually being deprecated by
>> Apple.  One victim is the MIDIPlugin which was written against a
>> ComponentManager API that, while Apple docs say is only deprecated,
>> has actually disappeared.  Consequently the MIDIPlugin support
>> (see http://www.squeakvm.org/svn/squeak/branches/Cog/platforms
>> /iOS/plugins/MIDIPlugin) needs completely rewriting to use Cocoa
>> APIs.  I've recently changed the build so that the MIDIPlgin is built
>> externally, which will make it easier to work on; one doesn't need to
>> build the entire VM, only the plugin.  I'm looking for volunteers who
>> a) love music/know MIDI
>> b) are happy programming at the Objective-C level using command-line
>> builds and perhaps Xcode, but more immediately lldb for debugging.
>>
>> If interested, reply to vm-dev and we can continue discussions there;
>> there are folks that can help with Mac OS support, but no one I know
>> of that has time to write this rather important plugin for multi-
>> media.  It would be a great shame to lose MIDI on Mac.
>
>     Perhaps this is an opportunity to reduce the platform code fanout a
> bit. I've had good results with Squeak MIDI before on Mac, Windows, and
> Linux, by making a VM plugin from the platform-independent PortMedia
> libraries (PortAudio and PortMidi), at [1]. Perhaps it would make sense
> to use PortMedia in combination with FFI/Alien these days.
>
>
> -C
>
> [1] http://portmedia.sourceforge.net
Why not re-implement MIDIPlugin in terms of PortMidi? That way even older images would benefit.

- Bert -




smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

re: Mac OS Cocoa MIDI Plugin

Eliot Miranda-2
In reply to this post by Craig Latta
 
Hi Craig,

On Thu, May 12, 2016 at 6:22 AM, Craig Latta <[hidden email]> wrote:


Hi Eliot--

> recently the Cog VM on Mac OS X moved to Cocoa, the Objective-C API
> for the platform, leaving behind the old Carbon C API.  There is some
> backward compatibility support but it is gradually being deprecated by
> Apple.  One victim is the MIDIPlugin which was written against a
> ComponentManager API that, while Apple docs say is only deprecated,
> has actually disappeared.  Consequently the MIDIPlugin support
> (see http://www.squeakvm.org/svn/squeak/branches/Cog/platforms
> /iOS/plugins/MIDIPlugin) needs completely rewriting to use Cocoa
> APIs.  I've recently changed the build so that the MIDIPlgin is built
> externally, which will make it easier to work on; one doesn't need to
> build the entire VM, only the plugin.  I'm looking for volunteers who
> a) love music/know MIDI
> b) are happy programming at the Objective-C level using command-line
> builds and perhaps Xcode, but more immediately lldb for debugging.
>
> If interested, reply to vm-dev and we can continue discussions there;
> there are folks that can help with Mac OS support, but no one I know
> of that has time to write this rather important plugin for multi-
> media.  It would be a great shame to lose MIDI on Mac.

     Perhaps this is an opportunity to reduce the platform code fanout a
bit. I've had good results with Squeak MIDI before on Mac, Windows, and
Linux, by making a VM plugin from the platform-independent PortMedia
libraries (PortAudio and PortMidi), at [1]. Perhaps it would make sense
to use PortMedia in combination with FFI/Alien these days.

I'm a bit wary of using it on linux because it claims to be implemented above ALSA and IME ALSA is poor, especially w.r.t. signals. But it looks like a good solution for Mac and Win.

Is there anything to stop you following Bert's suggestion of reimplementing the MIDIPlugin's support in terms of PortMIDI?

 
-C

[1] http://portmedia.sourceforge.net

--
Craig Latta
Black Page Digital
Amsterdam
[hidden email]
<a href="tel:%2B31%20%20%206%202757%207177" value="+31627577177">+31 6 2757 7177 (SMS ok)
<a href="tel:%2B%201%20415%20%20287%203547" value="+14152873547">+ 1 415 287 3547 (no SMS)

_,,,^..^,,,_
best, Eliot
Reply | Threaded
Open this post in threaded view
|

Re: Mac OS Cocoa MIDI Plugin

Tobias Pape
In reply to this post by Bert Freudenberg
 

On 17.05.2016, at 20:15, Bert Freudenberg <[hidden email]> wrote:

>
>> On 12.05.2016, at 15:22, Craig Latta <[hidden email]> wrote:
>>
>>
>>
>> Hi Eliot--
>>
>>> recently the Cog VM on Mac OS X moved to Cocoa, the Objective-C API
>>> for the platform, leaving behind the old Carbon C API.  There is some
>>> backward compatibility support but it is gradually being deprecated by
>>> Apple.  One victim is the MIDIPlugin which was written against a
>>> ComponentManager API that, while Apple docs say is only deprecated,
>>> has actually disappeared.  Consequently the MIDIPlugin support
>>> (see http://www.squeakvm.org/svn/squeak/branches/Cog/platforms
>>> /iOS/plugins/MIDIPlugin) needs completely rewriting to use Cocoa
>>> APIs.  I've recently changed the build so that the MIDIPlgin is built
>>> externally, which will make it easier to work on; one doesn't need to
>>> build the entire VM, only the plugin.  I'm looking for volunteers who
>>> a) love music/know MIDI
>>> b) are happy programming at the Objective-C level using command-line
>>> builds and perhaps Xcode, but more immediately lldb for debugging.
>>>
>>> If interested, reply to vm-dev and we can continue discussions there;
>>> there are folks that can help with Mac OS support, but no one I know
>>> of that has time to write this rather important plugin for multi-
>>> media.  It would be a great shame to lose MIDI on Mac.
>>
>>    Perhaps this is an opportunity to reduce the platform code fanout a
>> bit. I've had good results with Squeak MIDI before on Mac, Windows, and
>> Linux, by making a VM plugin from the platform-independent PortMedia
>> libraries (PortAudio and PortMidi), at [1]. Perhaps it would make sense
>> to use PortMedia in combination with FFI/Alien these days.
>>
>>
>> -C
>>
>> [1] http://portmedia.sourceforge.net
>
> Why not re-implement MIDIPlugin in terms of PortMidi? That way even older images would benefit.
Or timidity++ http://timidity.sourceforge.net/


>
> - Bert -



signature.asc (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

re: Mac OS Cocoa MIDI Plugin

timrowledge
In reply to this post by Eliot Miranda-2


> On 17-05-2016, at 11:44 AM, Eliot Miranda <[hidden email]> wrote:
>
> I'm a bit wary of using it on linux because it claims to be implemented above ALSA and IME ALSA is poor, especially w.r.t. signals. But it looks like a good solution for Mac and Win.

It gets more irritatingly complex; the latest release of Raspbian has added some support for bluetooth sound and apparently this has some great cosmic fight with ALSA that makes a Micheal Bay movie look like a Beatrix Potter story.

Let’s see if I can find a more coherent explanation (warning - I know too little about most of this to really judge ‘coherent’ very well)
From Simon Long @ Pi central - "One thing that has been added to this image is support for Bluetooth, which includes audio output over Bluetooth. Unfortunately, the BlueZ stack does not support audio over ALSA; the only way to get audio out to it is via PulseAudio, and it is impractical for various reasons to move all our audio support across to Pulse. This means that, for the time being, there is a rather kludgey hack implemented (by me, to my eternal shame…) in the LXPanel audio selector which starts PulseAudio when a Bluetooth device is selected (which also breaks ALSA) and then kills PulseAudio when a non-BT device is selected (which then unbreaks ALSA).

This is slightly clunky, but is hidden from the user, and it seems to work with most applications - web browsers, mplayer etc all seem to switch audio to the relevant output by this method.

So would pulseaudio save us from all this? I’ll try compiling a Pi vm with support for it sometime, though right now I’m cursing Scratch serial port support for the strange little sensor board. It seems to be ever so happily opening ports, doing nothing with them and closing them. Sigh.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Any Sufficiently Advanced Incompetence Is Indistinguishable From Malice

Reply | Threaded
Open this post in threaded view
|

Re: Mac OS Cocoa MIDI Plugin

Eliot Miranda-2
In reply to this post by Tobias Pape

Hi Tobias,


> On May 17, 2016, at 12:24 PM, Tobias Pape <[hidden email]> wrote:
>
>
>> On 17.05.2016, at 20:15, Bert Freudenberg <[hidden email]> wrote:
>>
>>
>>> On 12.05.2016, at 15:22, Craig Latta <[hidden email]> wrote:
>>>
>>>
>>>
>>> Hi Eliot--
>>>
>>>> recently the Cog VM on Mac OS X moved to Cocoa, the Objective-C API
>>>> for the platform, leaving behind the old Carbon C API.  There is some
>>>> backward compatibility support but it is gradually being deprecated by
>>>> Apple.  One victim is the MIDIPlugin which was written against a
>>>> ComponentManager API that, while Apple docs say is only deprecated,
>>>> has actually disappeared.  Consequently the MIDIPlugin support
>>>> (see http://www.squeakvm.org/svn/squeak/branches/Cog/platforms
>>>> /iOS/plugins/MIDIPlugin) needs completely rewriting to use Cocoa
>>>> APIs.  I've recently changed the build so that the MIDIPlgin is built
>>>> externally, which will make it easier to work on; one doesn't need to
>>>> build the entire VM, only the plugin.  I'm looking for volunteers who
>>>> a) love music/know MIDI
>>>> b) are happy programming at the Objective-C level using command-line
>>>> builds and perhaps Xcode, but more immediately lldb for debugging.
>>>>
>>>> If interested, reply to vm-dev and we can continue discussions there;
>>>> there are folks that can help with Mac OS support, but no one I know
>>>> of that has time to write this rather important plugin for multi-
>>>> media.  It would be a great shame to lose MIDI on Mac.
>>>
>>>   Perhaps this is an opportunity to reduce the platform code fanout a
>>> bit. I've had good results with Squeak MIDI before on Mac, Windows, and
>>> Linux, by making a VM plugin from the platform-independent PortMedia
>>> libraries (PortAudio and PortMidi), at [1]. Perhaps it would make sense
>>> to use PortMedia in combination with FFI/Alien these days.
>>>
>>>
>>> -C
>>>
>>> [1] http://portmedia.sourceforge.net
>>
>> Why not re-implement MIDIPlugin in terms of PortMidi? That way even older images would benefit.
>
> Or timidity++ http://timidity.sourceforge.net/

It's a software synth so doesn't fit serious use where one wants to send midi to ones own midi instruments, be they software synths or external modules.  Not to mention receiving midi data from external controllers.


_,,,^..^,,,_ (phone)
>>
>> - Bert -
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Mac OS Cocoa MIDI Plugin

timrowledge


> On 17-05-2016, at 12:36 PM, Eliot Miranda <[hidden email]> wrote:
>
>
> Hi Tobias,
>>
>> Or timidity++ http://timidity.sourceforge.net/
>
> It's a software synth so doesn't fit serious use where one wants to send midi to ones own midi instruments, be they software synths or external modules.  Not to mention receiving midi data from external controllers.
>

The current MIDI code does have a connection that makes timidity work, for certain values of work. It’s the current setup on the Pi and the changes were made some time ago by Manabu Sugiura - see https://www.raspberrypi.org/forums/viewtopic.php?f=77&t=88024&p=825177 and the code linked therefrom. The two issues I have with itare
a) it seems to take a long time (at least for the first few notes) to get any sound out to the hdmi or analogue outputs of the Pi
b) the timidity daemon seems to gradually ramp up it’s cpu usage until it is choking an entire core. I do’t know (yet) if this is a fault in the timidity code or in how we are driving it.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: XO: Execute Operator


Reply | Threaded
Open this post in threaded view
|

re: Mac OS Cocoa MIDI Plugin

Craig Latta
In reply to this post by Eliot Miranda-2
 

Hi--

     Eliot writes:

> I'm a bit wary of using it on linux because it claims to be
> implemented above ALSA and IME ALSA is poor, especially w.r.t.
> signals. But it looks like a good solution for Mac and Win.

     Does this mean you would rather use OSS than ALSA? As far as I
know, ALSA is the current supported audio device driver framework for
Linux, supplanting OSS.

     PulseAudio is not a device driver framework. It's a multi-platform
sound server which processes audio as it passes between an application
and device drivers (e.g., stream the audio over a network or to another
local application). It does provide an abstract API for the host
platform audio device driver frameworks it uses, but on Linux the audio
device driver framework it uses is ALSA.

     I found an enlightening and sad summary of the Linux audio
processing architecture[1] which, although written in 2010, seems to
jibe with the current Wikipedia pages for ALSA[2], PulseAudio[3],
JACK[4] (another sound server), and OSS[5], and with a similarly sad
Linux MIDI summary[6].

> Is there anything to stop you following Bert's suggestion of
> reimplementing the MIDIPlugin's support in terms of PortMIDI?

     Indeed no, that's what I was suggesting.

     Tim writes:

> The latest release of Raspbian has added some support for bluetooth
> sound and apparently this has some great cosmic fight with ALSA that
> makes a Micheal Bay movie look like a Beatrix Potter story.
>
> Let’s see if I can find a more coherent explanation (warning - I know
> too little about most of this to really judge ‘coherent’ very well)
>
> From Simon Long @ Pi central - "One thing that has been added to this
> image is support for Bluetooth, which includes audio output over
> Bluetooth. Unfortunately, the BlueZ stack does not support audio over
> ALSA; the only way to get audio out to it is via PulseAudio, and it
> is impractical for various reasons to move all our audio support
> across to Pulse. This means that, for the time being, there is a
> rather kludgey hack implemented (by me, to my eternal shame…) in the
> LXPanel audio selector which starts PulseAudio when a Bluetooth
> device is selected (which also breaks ALSA) and then kills PulseAudio
> when a non-BT device is selected (which then unbreaks ALSA).

     This implies that Raspian's PulseAudio implementation is broken,
and the cosmic fight between BlueZ and ALSA isn't a good excuse. :)  And
of course BlueZ is broken as well.

> So would pulseaudio save us from all this?

     No. :)  I would just live with Simon's BlueZ hack for now.


-C

[1] http://tuxradar.com/content/how-it-works-linux-audio-explained
[2] https://en.wikipedia.org/wiki/Advanced_Linux_Sound_Architecture
[3] https://en.wikipedia.org/wiki/PulseAudio
[4] https://en.wikipedia.org/wiki/JACK_Audio_Connection_Kit
[5] https://en.wikipedia.org/wiki/Open_Sound_System
[6] http://www.tedfelix.com/linux/linux-midi.html

--
Craig Latta
Black Page Digital
Amsterdam
[hidden email]
+31   6 2757 7177 (SMS ok)
+ 1 415  287 3547 (no SMS)

Reply | Threaded
Open this post in threaded view
|

re: Mac OS Cocoa MIDI Plugin

Eliot Miranda-2

Hi Craig,

> On May 18, 2016, at 2:28 AM, Craig Latta <[hidden email]> wrote:
>
>
>
> Hi--
>
>     Eliot writes:
>
>> I'm a bit wary of using it on linux because it claims to be
>> implemented above ALSA and IME ALSA is poor, especially w.r.t.
>> signals. But it looks like a good solution for Mac and Win.
>
>     Does this mean you would rather use OSS than ALSA? As far as I
> know, ALSA is the current supported audio device driver framework for
> Linux, supplanting OSS.

I just want things to work ;-). I remember the issue now.  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.

So if ALSA is the only game in town I guess we must get the code fixed.  How is ALSA maintained and by whom?  Is the code still broken as described above?


>
>     PulseAudio is not a device driver framework. It's a multi-platform
> sound server which processes audio as it passes between an application
> and device drivers (e.g., stream the audio over a network or to another
> local application). It does provide an abstract API for the host
> platform audio device driver frameworks it uses, but on Linux the audio
> device driver framework it uses is ALSA.
>
>     I found an enlightening and sad summary of the Linux audio
> processing architecture[1] which, although written in 2010, seems to
> jibe with the current Wikipedia pages for ALSA[2], PulseAudio[3],
> JACK[4] (another sound server), and OSS[5], and with a similarly sad
> Linux MIDI summary[6].

Il try and find time to read this.  Care to summarize?

>
>> Is there anything to stop you following Bert's suggestion of
>> reimplementing the MIDIPlugin's support in terms of PortMIDI?
>
>     Indeed no, that's what I was suggesting.
>
>     Tim writes:
>
>> The latest release of Raspbian has added some support for bluetooth
>> sound and apparently this has some great cosmic fight with ALSA that
>> makes a Micheal Bay movie look like a Beatrix Potter story.
>>
>> Let’s see if I can find a more coherent explanation (warning - I know
>> too little about most of this to really judge ‘coherent’ very well)
>>
>> From Simon Long @ Pi central - "One thing that has been added to this
>> image is support for Bluetooth, which includes audio output over
>> Bluetooth. Unfortunately, the BlueZ stack does not support audio over
>> ALSA; the only way to get audio out to it is via PulseAudio, and it
>> is impractical for various reasons to move all our audio support
>> across to Pulse. This means that, for the time being, there is a
>> rather kludgey hack implemented (by me, to my eternal shame…) in the
>> LXPanel audio selector which starts PulseAudio when a Bluetooth
>> device is selected (which also breaks ALSA) and then kills PulseAudio
>> when a non-BT device is selected (which then unbreaks ALSA).
>
>     This implies that Raspian's PulseAudio implementation is broken,
> and the cosmic fight between BlueZ and ALSA isn't a good excuse. :)  And
> of course BlueZ is broken as well.
>
>> So would pulseaudio save us from all this?
>
>     No. :)  I would just live with Simon's BlueZ hack for now.
>
>
> -C
>
> [1] http://tuxradar.com/content/how-it-works-linux-audio-explained
> [2] https://en.wikipedia.org/wiki/Advanced_Linux_Sound_Architecture
> [3] https://en.wikipedia.org/wiki/PulseAudio
> [4] https://en.wikipedia.org/wiki/JACK_Audio_Connection_Kit
> [5] https://en.wikipedia.org/wiki/Open_Sound_System
> [6] http://www.tedfelix.com/linux/linux-midi.html
>
> --
> Craig Latta
> Black Page Digital
> Amsterdam
> [hidden email]
> +31   6 2757 7177 (SMS ok)
> + 1 415  287 3547 (no SMS)


_,,,^..^,,,_ (phone)
Reply | Threaded
Open this post in threaded view
|

re: Mac OS Cocoa MIDI Plugin

Craig Latta
 

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. :)

> 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?

> > 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.


     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
[hidden email]
+31   6 2757 7177 (SMS ok)
+ 1 415  287 3547 (no SMS)

Reply | Threaded
Open this post in threaded view
|

re: Mac OS Cocoa MIDI Plugin

Eliot Miranda-2

Hi Craig,

> On May 20, 2016, at 4:02 AM, Craig Latta <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

re: Mac OS Cocoa MIDI Plugin

timrowledge


> On 20-05-2016, at 7:39 AM, Eliot Miranda <[hidden email]> wrote:
>
>
>
> The test is to start the image, play a sound, and then unload sound.  The gui used to stop responding to mouse clicks :-(

And - at least on a Pi - stop sockets working. Or crashed when a socket did something. Or something like that. The problem was that the handler got replaced by the default, which in a spectacular demonstration of insanity terminates your process. I think that might be even worse than central libraries that can’t chain signals properly.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: RP: Read Printer


Reply | Threaded
Open this post in threaded view
|

re: Mac OS Cocoa MIDI Plugin

Eliot Miranda-2
In reply to this post by Craig Latta
 
Hi Craig,

On Fri, May 20, 2016 at 4:02 AM, Craig Latta <[hidden email]> 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. :)

> 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?

Thanks for the links.  I checked-out alas-lib (via ) today and indeed the code is still broken.  Look at the sigaction calls in src/async.c and they don't ask for the old action.  I'll try contacting the authors and suggesting they fix things.

> > 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.


     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
[hidden email]
<a href="tel:%2B31%20%20%206%202757%207177" value="+31627577177">+31 6 2757 7177 (SMS ok)
<a href="tel:%2B%201%20415%20%20287%203547" value="+14152873547">+ 1 415 287 3547 (no SMS)

_,,,^..^,,,_
best, Eliot