4 ms·

Big Patch Series Prepares the Linux Audio Drivers for MIDI 2.0

51 points by jlpcsl 3y ago

smoldesu 3y ago
> Linux sound subsystem maintainer Takashi Iwai of SUSE sent out the set of 36 patches All in SysEx format, I presume? :p Sorry, that's some low hanging sound design/kernel programming intersectional humor. This is cool stuff though, I've been a happy camper using Linux for sound design ever since Bitwig picked up native PipeWire support. These patches will be nice to have for MPE setups in the future!
notmypenguin 3y ago
It’s not a drop-in replacement. MIDI is simple enough to trigger something with a single pin going high low. It’s basically a close to bare metal switching you can get, you can implement it on an arduino 8 bit MCU or worse. MIDI doesn’t even have the transport timed?! the rate the data flows at is the timing you get. Now this MIDI 2.0 is for computers and it’s fancy and undoubtedly does everything even make coffee. This MIDI 2.0 is basically a competitive protocol to OSC, not MIDI More layers, more complexity, let alone USB endpoints and software timers = this is not going to be the fun thing everyone thinks it will. Anyone played with a Waldorf product called the Blofeld? You feel latency that varies while you turn knobs in local-on mode! I’m not saying all implementations of hardware synths will feel bad in the future, but there is a giant ball of denial as to how newer not so embedded systems perform.
- someweirdperson 3y ago
  > MIDI is simple enough to trigger something with a single pin going high low. MIDI is not high / low but current on / current off.
  - henearkr 3y ago
    Isn't it roughly the same, if the IO you're speaking to is pulled down through a resistor to the ground?
    - cma 3y ago
      Doesn't MIDI require optical isolators and the only part connected to ground is the cable shielding?
      - detaro 3y ago
        "require". But even if you add them (you should!), it's not like driving it gets any more complicated on the controller/software side, which is what notmypenguin was talking about I think
      - henearkr 3y ago
        And if they are pulled down to a low reference voltage independent from the ground? (thx, I didn't knwow about required independence from the ground)
        colanderman 3y ago
        The input to an optoisolator (i.e., an LED) is two pins, with no reference to ground. So either current is flowing through the opto's input, or not. Because they're not referenced to ground (or any voltage), the voltage on either pin relative to ground is irrelevant. (In this way, two connected MIDI devices can have different ideas of what signal ground is without causing issues.)
  - colanderman 3y ago
    The reality is "somewhere in between". It's actually specified as a voltage source with a fixed impedance [1]. Tricks like snaking the signal in series through multiple receivers don't really work; whereas tricks like sourcing +5 VDC from the connector do work. But it is correct that the current which ends up flowing through the connection is what determines the bits sent (by virtue of the receiver being an optocoupler, not an op-amps). [1] https://midi.org/specifications/midi1-specifications/midi-1-addenda/5-pin-din-electrical-specs https://midi.org/specifications/midi1-specifications/midi-1-...
perlgeek 3y ago
Why do such drivers need to live in the kernel? (Genuine question from me due to lack of context/understanding, not trying to critique anyone) Lots of audio processing is already happening in userspace (think pulseaudio / pipewire), and putting USB drivers in userspace is also something that I think would simplify development. Or is there no ready-made infrastructure for that yet?
- chpatrick 3y ago
  Low latency perhaps?
- squarefoot 3y ago
  I'm just speculating, but this might have to do with further potential development of Linux based music oriented devices, or possibly a more aggressive latency reduction down to near realtime, although userspace should allow that anyway.
- rektide 3y ago
  I think it would make app development much more complex to have to find & use a midi stack, versus having midi devices well handled & a nice standard interface available. We could all be using user land networking stacks too over raw sockets but we don't do that either. Yeah, it too is simpler for the kernel. One of the key roles of the OS is to abstract access to resources. Turns out that's kind of useful.

51 points by jlpcsl 3y ago

> Linux sound subsystem maintainer Takashi Iwai of SUSE sent out the set of 36 patches All in SysEx format, I presume? :p Sorry, that's some low hanging sound design/kernel programming intersectional humor. This is cool stuff though, I've been a happy camper using Linux for sound design ever since Bitwig picked up native PipeWire support. These patches will be nice to have for MPE setups in the future!

notmypenguin 3y ago

It’s not a drop-in replacement. MIDI is simple enough to trigger something with a single pin going high low. It’s basically a close to bare metal switching you can get, you can implement it on an arduino 8 bit MCU or worse. MIDI doesn’t even have the transport timed?! the rate the data flows at is the timing you get. Now this MIDI 2.0 is for computers and it’s fancy and undoubtedly does everything even make coffee. This MIDI 2.0 is basically a competitive protocol to OSC, not MIDI More layers, more complexity, let alone USB endpoints and software timers = this is not going to be the fun thing everyone thinks it will. Anyone played with a Waldorf product called the Blofeld? You feel latency that varies while you turn knobs in local-on mode! I’m not saying all implementations of hardware synths will feel bad in the future, but there is a giant ball of denial as to how newer not so embedded systems perform.

someweirdperson 3y ago
> MIDI is simple enough to trigger something with a single pin going high low. MIDI is not high / low but current on / current off.
- henearkr 3y ago
  Isn't it roughly the same, if the IO you're speaking to is pulled down through a resistor to the ground?
  - cma 3y ago
    Doesn't MIDI require optical isolators and the only part connected to ground is the cable shielding?
    - detaro 3y ago
      "require". But even if you add them (you should!), it's not like driving it gets any more complicated on the controller/software side, which is what notmypenguin was talking about I think
    - henearkr 3y ago
      And if they are pulled down to a low reference voltage independent from the ground? (thx, I didn't knwow about required independence from the ground)
      - colanderman 3y ago
        The input to an optoisolator (i.e., an LED) is two pins, with no reference to ground. So either current is flowing through the opto's input, or not. Because they're not referenced to ground (or any voltage), the voltage on either pin relative to ground is irrelevant. (In this way, two connected MIDI devices can have different ideas of what signal ground is without causing issues.)
- colanderman 3y ago
  The reality is "somewhere in between". It's actually specified as a voltage source with a fixed impedance [1]. Tricks like snaking the signal in series through multiple receivers don't really work; whereas tricks like sourcing +5 VDC from the connector do work. But it is correct that the current which ends up flowing through the connection is what determines the bits sent (by virtue of the receiver being an optocoupler, not an op-amps). [1] https://midi.org/specifications/midi1-specifications/midi-1-addenda/5-pin-din-electrical-specs https://midi.org/specifications/midi1-specifications/midi-1-...

perlgeek 3y ago

Why do such drivers need to live in the kernel? (Genuine question from me due to lack of context/understanding, not trying to critique anyone) Lots of audio processing is already happening in userspace (think pulseaudio / pipewire), and putting USB drivers in userspace is also something that I think would simplify development. Or is there no ready-made infrastructure for that yet?

chpatrick 3y ago
Low latency perhaps?
squarefoot 3y ago
I'm just speculating, but this might have to do with further potential development of Linux based music oriented devices, or possibly a more aggressive latency reduction down to near realtime, although userspace should allow that anyway.
rektide 3y ago
I think it would make app development much more complex to have to find & use a midi stack, versus having midi devices well handled & a nice standard interface available. We could all be using user land networking stacks too over raw sockets but we don't do that either. Yeah, it too is simpler for the kernel. One of the key roles of the OS is to abstract access to resources. Turns out that's kind of useful.