13 Jun
2022
13 Jun
'22
12:56 a.m.
Hey hey,
my two old Delta 1010 cards are definitely dying now. So I need replacement
for all those analog I/Os. I have found three candidates: Behringer X Air
XR18, Presonus ARC16C and Tascam u16x08(?) and would be glad if anyone could
share experiences with them under Linux. I'm also looking for further
alternatives (see my minimum requirements below). I definitely need
multichannel audio coming from the device.
The Tascan appears to have many microphone inputs, which cannot serve for line
level input, if that really is so, it's out.
The Behringer requires the app, which I have not been able to test, but its
accessibility is not that important, if the XR18 will remember settings across
power cycles.
The ARC16C's description reads very well, but there are many dubious reviews,
perhaps it was an early "Monday" manufacturing problem though.
My requirements: one mic in (no need for +48V phantom power), one instrument
in (Clavinet, I think it needs extra amping), at least 12 line level ins, 14
preferred. Four outputs (main out and to "sends" to outboard). No DSP,
routing/bussing,... My workflow is purely centred in the box, using JACK for
all connections.
Based on the three candidates, I'd say my price range has to go up to 700 EUR.
Any experiences and further suggestions are very much appreciated!
Best wishes,
Jeanette
--
* Website: http://juliencoder.de - for summer is a state of sound
* Youtube: https://www.youtube.com/channel/UCMS4rfGrTwz8W7jhC1Jnv7g
* Audiobombs: https://www.audiobombs.com/users/jeanette_c
* GitHub: https://github.com/jeanette-c
But tell me what happens when it stops? <3
(Britney Spears)
13 Jun
13 Jun
3:15 p.m.
Jeanette,
what about a Behringer umc1820 plus an external AD converter to make use
of its 8 ADAT inputs? Class compliant. no DSP etc.
best, P
* Jeanette C. <julien(a)mail.upb.de> [2022-06-12 22:57]:
Hey hey,
my two old Delta 1010 cards are definitely dying now. So I need replacement
for all those analog I/Os. I have found three candidates: Behringer X Air
XR18, Presonus ARC16C and Tascam u16x08(?) and would be glad if anyone could
share experiences with them under Linux. I'm also looking for further
alternatives (see my minimum requirements below). I definitely need
multichannel audio coming from the device.
The Tascan appears to have many microphone inputs, which cannot serve for
line level input, if that really is so, it's out.
The Behringer requires the app, which I have not been able to test, but its
accessibility is not that important, if the XR18 will remember settings
across power cycles.
The ARC16C's description reads very well, but there are many dubious
reviews, perhaps it was an early "Monday" manufacturing problem though.
My requirements: one mic in (no need for +48V phantom power), one instrument
in (Clavinet, I think it needs extra amping), at least 12 line level ins, 14
preferred. Four outputs (main out and to "sends" to outboard). No DSP,
routing/bussing,... My workflow is purely centred in the box, using JACK for
all connections.
Based on the three candidates, I'd say my price range has to go up to 700 EUR.
Any experiences and further suggestions are very much appreciated!
Best wishes,
Jeanette
--
* Website: http://juliencoder.de - for summer is a state of sound
* Youtube: https://www.youtube.com/channel/UCMS4rfGrTwz8W7jhC1Jnv7g
* Audiobombs: https://www.audiobombs.com/users/jeanette_c
* GitHub: https://github.com/jeanette-c
But tell me what happens when it stops? <3
(Britney Spears)
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-user
4 p.m.
Hi Peter!
Jun 13 2022, Peter P. has written:
...
what about a Behringer umc1820 plus an external AD
converter to make use
of its 8 ADAT inputs?
...
Going with that route there are quite a few good choices, I would love
to avoid an ADAT expander as much as possible though, for several
reasons.
1. Bad experience in the past
2. One extra power plug, which I can ill afford with 17 devices already
plugged in. :(
3. Depending on the interface the price, though not a big concern for
the UMC1820.
I must admit it looks good, as do the Scarlett 18i20 and one or two
others.
Best wishes,
Jeanette
--
* Website: http://juliencoder.de - for summer is a state of sound
* Youtube: https://www.youtube.com/channel/UCMS4rfGrTwz8W7jhC1Jnv7g
* Audiobombs: https://www.audiobombs.com/users/jeanette_c
* GitHub: https://github.com/jeanette-c
I'm reaching out to you
To find that you're not there <3
(Britney Spears)
4:29 p.m.
Am 12.06.22 um 22:57 schrieb Jeanette C.:
[...] Behringer X Air XR18 [...]
The Behringer requires the app, which I have not been able to test,
but its
accessibility is not that important, if the XR18 will remember
settings across power cycles. [...]
Any experiences and further suggestions are very much appreciated!
I have the MIDAS MR18, which is the same as the XR18 but with better
pre-amps and no instrument inputs.
The device is rather bulky, when viewed as an audio interface.
The provided app works well under Linux, you can install it on Arch
Linux via the AUR [1] [2]. There are solutions for command line control
of the device in varying states of polishedness.
The app and the mixer communicate via OSC, so you need a network
connection, which can be via wifi or ethernet. The built-in wifi isn't
very good, so I used a raspberry pi 3 connected via ethernet to the MR18
and via wifi to my network as a gateway (so I didn't need to run an
ethernet cable across the room).
The device starts up with the main mixer outputs muted, so you need the
app for getting things started.
There's also an Android tablet app and a third-party Android app with a
few more convenience features.
The device can be switched between 2x2 and multi-channel (18 in / 6 out
IIRC) audio interface operation. Both work out of the box with ALSA / JACK.
Since the device is actually a full-fledged digital mixer it provides a
channel strip with EQ and compressor per channel, complex routing
options and built-in digital effects.
I have used the MR18 as the hub of my synth wall, mainly only as a sub
mixer, but I also tried using it as an audio interface and did a few
test recordings using it as a multi-channel audio interface and
encountered no major problems, besides the complexity of setting up the
routing.
Chris
[1] https://aur.archlinux.org/packages/m-air-edit-bin
[2] https://aur.archlinux.org/packages/xairedit
7:42 p.m.
Am 12.06.22 um 22:57 schrieb Jeanette C.:
Hey hey,
my two old Delta 1010 cards are definitely dying now. So I need
replacement for all those analog I/Os. I have found three candidates:
Behringer X Air XR18, Presonus ARC16C and Tascam u16x08(?) and would
be glad if anyone could share experiences with them under Linux. I'm
also looking for further alternatives (see my minimum requirements
below). I definitely need multichannel audio coming from the device.
The Tascan appears to have many microphone inputs, which cannot serve
for line level input, if that really is so, it's out.
The Behringer requires the app, which I have not been able to test,
but its accessibility is not that important, if the XR18 will remember
settings across power cycles.
I have the XR18 for some years now and I am really happy with it. The
things that Christopher mentioned in his post for the MR18 are also true
for the XR18. You need the app up and running to unmute the device. But
the app works very well on my Debian 10 machine. The app covers
everything the XR18 can do and is really useful. At least you want to
have the mute button accessible in case something went wrong ;-).
I do not know if the preamps from the XR18 are not that good as for the
MR18 but for me they sound very good. (But I am not a professional
musician. Just a guitar player that makes music for fun as a hobby. So
my ears might be not that good that I would hear the difference.)
For my Linux setup I use of course Jack then mostly Tuxguitar, Musecore
and Ardour. And sometimes other programs that you can install on a Linux
system. For analogue connections I have of course various guitars in
various setups plugged (modellers and cab simulations) to the XR18 and
never had a problem. I also have a Roland Synthesizer and a Roland
MC-101 and to MIDI Keyboards. Everything works well and without any
problems with the XR18.
Before the XR18 I had the UMC1820 with the Behringer ADAT device. Both
worked very well for me on the same Debian 10 system for a long time. I
changed to the XR18 because I wanted to have an app to control the sound
card easily via mouse and monitor.
Hope this helps you somehow,
Michael
7:50 p.m.
Hi Michael,
I will have to run the app on an ipad, which is fine. Does the XR18 remember
all the settings across power cycles, once they are made? Will the device run
if the app is not open on a controlling device? The iPad is not strictly my
own and so I can't rely on it being near me whenever I record or play.
Best wishes and thanks,
Jeanette
--
* Website: http://juliencoder.de - for summer is a state of sound
* Youtube: https://www.youtube.com/channel/UCMS4rfGrTwz8W7jhC1Jnv7g
* Audiobombs: https://www.audiobombs.com/users/jeanette_c
* GitHub: https://github.com/jeanette-c
Where are you now, what have you found
Where is your heart, when I'm not around <3
(Britney Spears)
8:17 p.m.
Hi Jeanette,
Hi Michael,
I will have to run the app on an ipad, which is fine. Does the XR18
remember all the settings across power cycles, once they are made?
Will the device run if the app is not open on a controlling device?
The iPad is not strictly my own and so I can't rely on it being near
me whenever I record or play.
I just closed the app for a test and the XR18 still works and is playing
music ;-).
Whenever I start the app it asks me if I want to transfer the current
settings "mixer->pc" or "pc->mixer" so you can decide on
whatever you
need. And of course with "mixer->pc" you restore the last settings on
the XR18. You can also save setups on a computer, pad and so on. Very
useful if you have different live situations with different instrument
setups and so on.
I also use jack_mixer in my setup to have a volume control for stuff
that runs on my computer and goes via USB to the stereo port (channel
17/18) on the XR18. If you wire jack_mixer (or any other Jack aware
mixer program) accordingly you could also have a volume control without
needing the app. You would only need the app to unmute it.
And another thing: I use external studio monitors connected to the main
outs of the XR18. With this setup I never experienced any latency
issues. (But again I am not a professional musician and others might
have other experiences and see it differently.)
Hope this helps again,
Michael
14 Jun
14 Jun
5:24 p.m.
Hey Jeanette,
I wanted to tell you my experience with the Tascam US-16x08 on Linux.
First off, it works and shows up under alsa. You get the inputs and
outputs which is really nice.
Now for the downside: it has its own proprietary software that doesn't
exist on Linux for digital processing and mixing. Basically, the
interface has its own mixing utility that also allows one to apply
limited dsp effects and mix/route audio. If you wanted to stay solely on
Linux, this cannot be used.
Now, if you buy the interface and it has a clean slate for its digital
mixing/processing state, it may work just fine for your needs. But, if
you buy it used, you may have to change it to that clean/stock slate first.
Let me know if you have any questions about the Tascam US-16x08, as it
literally is sitting next to me at work and I can just plug it in and
try out things for you when I have free time.
Brandon Hale
On 6/12/22 4:57 PM, Jeanette C. wrote:
Hey hey,
my two old Delta 1010 cards are definitely dying now. So I need
replacement for all those analog I/Os. I have found three candidates:
Behringer X Air XR18, Presonus ARC16C and Tascam u16x08(?) and would
be glad if anyone could share experiences with them under Linux. I'm
also looking for further alternatives (see my minimum requirements
below). I definitely need multichannel audio coming from the device.
The Tascan appears to have many microphone inputs, which cannot serve
for line level input, if that really is so, it's out.
The Behringer requires the app, which I have not been able to test,
but its accessibility is not that important, if the XR18 will remember
settings across power cycles.
The ARC16C's description reads very well, but there are many dubious
reviews, perhaps it was an early "Monday" manufacturing problem though.
My requirements: one mic in (no need for +48V phantom power), one
instrument in (Clavinet, I think it needs extra amping), at least 12
line level ins, 14 preferred. Four outputs (main out and to "sends" to
outboard). No DSP, routing/bussing,... My workflow is purely centred
in the box, using JACK for all connections.
Based on the three candidates, I'd say my price range has to go up to
700 EUR.
Any experiences and further suggestions are very much appreciated!
Best wishes,
Jeanette
6:09 p.m.
Hi list,
* Brandon Hale <bthaleproductions(a)gmail.com> [2022-06-14 15:24]:
[...]
Now for the downside: it has its own proprietary
software that doesn't exist
on Linux for digital processing and mixing. Basically, the interface has its
own mixing utility that also allows one to apply limited dsp effects and
mix/route audio. If you wanted to stay solely on Linux, this cannot be used.
That's the case with many USB audio interfaces in fact. I amquite
stubborn in this regard and don't want to pay for features that I will
not be able to use (especially sever with current RME devices). It is
hard to find multichannel class-compliant USB interfaces that don't
require some proprietary program. The Behringer umc1820 seems to be one.
Anyone knows other such interfaces?
best, P
7:26 p.m.
Motu AVB Interface are class complaint and can be managed over ethernet,
has onboard mixer for local channels as well as AVB streams.
In theory, an optimal solution that can scale up to hundreds of channels as
well as hundreds of meters.. but in practice, not so.
The USB implementation is buggy and to get it nice and stable, you need a
very old firmware (which doesn't always work on newer revisions) or a
kernel patch.
I have 3 Motu AVB devices but I cannot recommend them for linux usage.
On Tue, Jun 14, 2022, 16:10 Peter P. <peterparker(a)fastmail.com> wrote:
Hi list,
* Brandon Hale <bthaleproductions(a)gmail.com> [2022-06-14 15:24]:
[...]
Now for the downside: it has its own proprietary
software that doesn't
exist
on Linux for digital processing and mixing.
Basically, the interface has
its
own mixing utility that also allows one to apply
limited dsp effects and
mix/route audio. If you wanted to stay solely on Linux, this cannot be
used.
That's the case with many USB audio interfaces in fact. I amquite
stubborn in this regard and don't want to pay for features that I will
not be able to use (especially sever with current RME devices). It is
hard to find multichannel class-compliant USB interfaces that don't
require some proprietary program. The Behringer umc1820 seems to be one.
Anyone knows other such interfaces?
best, P
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-user
8:43 p.m.
Rme has their own proprietary ways of dealing with usb quirks and providing error
detection and correction, while keeping low latency. They do a pretty good job, but
unfortunately, the details are not shared.
I’m personally quite fund of their (current range of) pcie cards on Linux (except madi-fx,
which only has a work in progress driver on Linux - but rme can share the info to develop
it further if anyone wants). The aio pro card has 2 analog ins and outs. If you need more,
they have excellent ad-da converters that work flawlessly with the pcie cards on Linux (at
least when using jack, which I always do, I have limited experience with using Alsa
directly for audio I/o and none with soundwire - still on the todo list).
People looking into entering the world of ip audio, in particular Dante or avb, will
appreciate their convertor boxes, esp. to madi. 0,7 msecs additional latency only.
But it will cost you more than 700 euros to get set up.
Best, ph
Philippe Bekaert
Op 14 jun. 2022 om 17:28 heeft Anders Hellquist
<lau(a)hellquist.net> het volgende geschreven:
Motu AVB Interface are class complaint and can be managed over ethernet, has onboard
mixer for local channels as well as AVB streams.
In theory, an optimal solution that can scale up to hundreds of channels as well as
hundreds of meters.. but in practice, not so.
The USB implementation is buggy and to get it nice and stable, you need a very old
firmware (which doesn't always work on newer revisions) or a kernel patch.
I have 3 Motu AVB devices but I cannot recommend them for linux usage.
On Tue, Jun 14, 2022, 16:10 Peter P.
<peterparker(a)fastmail.com> wrote:
Hi list,
* Brandon Hale <bthaleproductions(a)gmail.com> [2022-06-14 15:24]:
[...]
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-user Now for the downside: it has its own proprietary
software that doesn't exist
on Linux for digital processing and mixing. Basically, the interface has its
own mixing utility that also allows one to apply limited dsp effects and
mix/route audio. If you wanted to stay solely on Linux, this cannot be used.
That's the case with many USB audio interfaces in fact. I amquite
stubborn in this regard and don't want to pay for features that I will
not be able to use (especially sever with current RME devices). It is
hard to find multichannel class-compliant USB interfaces that don't
require some proprietary program. The Behringer umc1820 seems to be one.
Anyone knows other such interfaces?
best, P
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-user
8:54 p.m.
Philippe,
* Philippe Bekaert <linux(a)panokkel.be> [2022-06-14 18:43]:
[...]
I’m personally quite fund of their (current range of)
pcie cards on Linux
Thanks for mentioning these. Indeed excellent cards it seems.
Forgot to
mention that in my case (lots of live work) I need a laptop card.
[...]
People looking into entering the world of ip audio, in
particular Dante or avb, will appreciate their convertor boxes, esp. to madi. 0,7 msecs
additional latency only.
The last time I recherched, there was no usable
(non-Motu)
class-compliant Dante or AVB card for Linux laptops. Does anyone know if
this has changed?
Thanks again!
9:21 p.m.
"Peter P." <peterparker(a)fastmail.com> writes:
Philippe,
* Philippe Bekaert <linux(a)panokkel.be> [2022-06-14 18:43]:
[...]
It's sort of embarrassing but the Hammerfall DSP cards work with either
the Expresscard adapter or an Expresscard-to-Cardbus adapter (the latter
_has_ to map the PCI express lane of the Expresscard slot, not the USB
lane) with the old Cardbus adapter. It's ancient technology with 8
line-in/line-out connectors and quite robust ADAT support, but in terms
of the quality and latency of the available connections and driver
support, it's still unprecedented.
The Expresscard-to-Cardbus adapter solution is not overly convincing
mechanically. And you need to dig up the firmware for 64bit versions of
Linux (no idea where I got my .deb from when I needed to upgrade).
And of course, Expresscard slots are a dying breed as well.
--
David Kastrup
I’m personally quite fund of their (current range
of) pcie cards on Linux
Thanks for mentioning these. Indeed excellent cards it
seems. Forgot to
mention that in my case (lots of live work) I need a laptop card.
[...]
People looking into entering the world of ip
audio, in particular
Dante or avb, will appreciate their convertor boxes, esp. to
madi. 0,7 msecs additional latency only.
The last time I recherched, there was no
usable (non-Motu)
class-compliant Dante or AVB card for Linux laptops. Does anyone know if
this has changed?
10 p.m.
Most of the pcie cards (in fact, all of them in single speed mode) work absolutely fine on
my laptop, given a sonnet echo express IIIe thunderbolt to pcie box.
As said, my set up set me back more than 700 euros …
I have a rme Dante-to-madi usb box here. Never checked usb audio class compliant mode.
Will do.
Best, ph
Philippe Bekaert
Op 14 jun. 2022 om 19:23 heeft David Kastrup
<dak(a)gnu.org> het volgende geschreven:
"Peter P." <peterparker(a)fastmail.com> writes:
Philippe,
* Philippe Bekaert <linux(a)panokkel.be> [2022-06-14 18:43]:
[...]
It's sort of embarrassing but the Hammerfall DSP cards work with either
the Expresscard adapter or an Expresscard-to-Cardbus adapter (the latter
_has_ to map the PCI express lane of the Expresscard slot, not the USB
lane) with the old Cardbus adapter. It's ancient technology with 8
line-in/line-out connectors and quite robust ADAT support, but in terms
of the quality and latency of the available connections and driver
support, it's still unprecedented.
The Expresscard-to-Cardbus adapter solution is not overly convincing
mechanically. And you need to dig up the firmware for 64bit versions of
Linux (no idea where I got my .deb from when I needed to upgrade).
And of course, Expresscard slots are a dying breed as well.
--
David Kastrup
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-user I’m personally quite fund of their (current range
of) pcie cards on Linux
Thanks for mentioning these. Indeed excellent cards it
seems. Forgot to
mention that in my case (lots of live work) I need a laptop card.
[...]
People looking into entering the world of ip
audio, in particular
Dante or avb, will appreciate their convertor boxes, esp. to
madi. 0,7 msecs additional latency only.
The last time I recherched, there was no
usable (non-Motu)
class-compliant Dante or AVB card for Linux laptops. Does anyone know if
this has changed?
10:04 p.m.
Dante: merging technologies has an open source software aes67 driver for Linux. However,
the user space configuration tool is closed source. Dante has a aes67 compatibility mode.
Best, ph
Philippe Bekaert
Op 14 jun. 2022 om 20:00 heeft Philippe Bekaert
<linux(a)panokkel.be> het volgende geschreven:
Most of the pcie cards (in fact, all of them in single speed mode) work absolutely fine
on my laptop, given a sonnet echo express IIIe thunderbolt to pcie box.
As said, my set up set me back more than 700 euros …
I have a rme Dante-to-madi usb box here. Never checked usb audio class compliant mode.
Will do.
Best, ph
Philippe Bekaert
> Op 14 jun. 2022 om 19:23 heeft David Kastrup <dak(a)gnu.org> het volgende
geschreven:
>
> "Peter P." <peterparker(a)fastmail.com> writes:
>
>> Philippe,
>>
>> * Philippe Bekaert <linux(a)panokkel.be> [2022-06-14 18:43]:
>> [...]
>>> I’m personally quite fund of their (current range of) pcie cards on Linux
>> Thanks for mentioning these. Indeed excellent cards it seems. Forgot to
>> mention that in my case (lots of live work) I need a laptop card.
>>
>> [...]
>>> People looking into entering the world of ip audio, in particular
>>> Dante or avb, will appreciate their convertor boxes, esp. to
>>> madi. 0,7 msecs additional latency only.
>> The last time I recherched, there was no usable (non-Motu)
>> class-compliant Dante or AVB card for Linux laptops. Does anyone know if
>> this has changed?
>
> It's sort of embarrassing but the Hammerfall DSP cards work with either
> the Expresscard adapter or an Expresscard-to-Cardbus adapter (the latter
> _has_ to map the PCI express lane of the Expresscard slot, not the USB
> lane) with the old Cardbus adapter. It's ancient technology with 8
> line-in/line-out connectors and quite robust ADAT support, but in terms
> of the quality and latency of the available connections and driver
> support, it's still unprecedented.
>
> The Expresscard-to-Cardbus adapter solution is not overly convincing
> mechanically. And you need to dig up the firmware for 64bit versions of
> Linux (no idea where I got my .deb from when I needed to upgrade).
>
> And of course, Expresscard slots are a dying breed as well.
>
> --
> David Kastrup
> _______________________________________________
> Linux-audio-user mailing list
> Linux-audio-user(a)lists.linuxaudio.org
> https://lists.linuxaudio.org/listinfo/linux-audio-user
15 Jun
15 Jun
12:29 a.m.
On Tue, June 14, 2022 1:04 pm, Philippe Bekaert wrote:
Dante: merging technologies has an open source
software aes67 driver for
Linux. However, the user space configuration tool is closed source.
Merging developers do not keep the driver up to date with changing kernel
requirements. The Merging driver does not compile with the last year or
more of kernel versions, but Andrea Bondavalli has created some patches
which allow the driver to build with the latest kernels, as well as a GPL
user space daemon to replace the closed source Merging tool.
https://github.com/bondagit/
If you download the AES67 daemon project it will download and build the
patched ravenna-alsa-driver into the "3rd party" subdirectory.
--
Chris Caudle
12:41 a.m.
"Chris Caudle" <6807.chris(a)pop.powweb.com> writes:
On Tue, June 14, 2022 1:04 pm, Philippe Bekaert
wrote:
Sort of annoying, given that Linux has been around for 30 years or so,
powers _all_ of the top 100 supercomputers (last time I looked) and is
the most installed kernel in the world (Android uses it). Still, nobody
feels there is a point in supporting it. Well ok, Intel GPU support
tends to be comparatively useful. And the class-compliant part of
class-compliant devices tends to work.
But somehow that's not all too different from the state 20 years ago.
--
David Kastrup
Dante: merging technologies has an open source
software aes67 driver for
Linux. However, the user space configuration tool is closed source.
Merging developers do not keep the driver up to date with changing kernel
requirements. The Merging driver does not compile with the last year or
more of kernel versions, but Andrea Bondavalli has created some patches
which allow the driver to build with the latest kernels, as well as a GPL
user space daemon to replace the closed source Merging tool.
https://github.com/bondagit/
If you download the AES67 daemon project it will download and build the
patched ravenna-alsa-driver into the "3rd party" subdirectory.
1:37 a.m.
I’m not that pessimistic. I’m often programming against frame grabber and Sdi cards, and
even though not everything is fully open source (a lot is), I find there is considerable
support for Linux. More so than in the past. Some companies do not, but you can do without
them.
Companies like rme apparently do not have much resources for doing their own Linux driver
development but they really are helpful to those who want to do. On the other hand, they
do have an edge wrt competition and are reluctant indeed to give out certain information
that you really would love to use.
Talking about audio on Linux, things are not perfect on the Linux side either. There is
some good documentation, eg, but audio on platforms like macOS is considerably better
documented. The Linux adagium that the source code is the ultimate documentation, is not
that widely accepted outside the Linux universe. Though I have 40 years of experience with
c, and was a Linux user since 91, I’m often scratching my head studying the alsa driver
core. It’s really not so easy …
Best, ph
Philippe Bekaert
Op 14 jun. 2022 om 22:43 heeft David Kastrup
<dak(a)gnu.org> het volgende geschreven:
"Chris Caudle" <6807.chris(a)pop.powweb.com> writes:
Sort of annoying, given that Linux has been around for 30 years or so,
powers _all_ of the top 100 supercomputers (last time I looked) and is
the most installed kernel in the world (Android uses it). Still, nobody
feels there is a point in supporting it. Well ok, Intel GPU support
tends to be comparatively useful. And the class-compliant part of
class-compliant devices tends to work.
But somehow that's not all too different from the state 20 years ago.
--
David Kastrup
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-user
On Tue,
June 14, 2022 1:04 pm, Philippe Bekaert wrote:
Dante: merging technologies has an open source software aes67 driver for
Linux. However, the user space configuration tool is closed source.
Merging developers do not keep the driver up to date with changing kernel
requirements. The Merging driver does not compile with the last year or
more of kernel versions, but Andrea Bondavalli has created some patches
which allow the driver to build with the latest kernels, as well as a GPL
user space daemon to replace the closed source Merging tool.
https://github.com/bondagit/
If you download the AES67 daemon project it will download and build the
patched ravenna-alsa-driver into the "3rd party" subdirectory.
1:40 a.m.
40 —> 33 sorry. Since 88 … ph
Philippe Bekaert
Op 14 jun. 2022 om 23:36 heeft Philippe Bekaert
<linux(a)panokkel.be> het volgende geschreven:
I’m not that pessimistic. I’m often programming against frame grabber and Sdi cards, and
even though not everything is fully open source (a lot is), I find there is considerable
support for Linux. More so than in the past. Some companies do not, but you can do without
them.
Companies like rme apparently do not have much resources for doing their own Linux driver
development but they really are helpful to those who want to do. On the other hand, they
do have an edge wrt competition and are reluctant indeed to give out certain information
that you really would love to use.
Talking about audio on Linux, things are not perfect on the Linux side either. There is
some good documentation, eg, but audio on platforms like macOS is considerably better
documented. The Linux adagium that the source code is the ultimate documentation, is not
that widely accepted outside the Linux universe. Though I have 40 years of experience with
c, and was a Linux user since 91, I’m often scratching my head studying the alsa driver
core. It’s really not so easy …
Best, ph
Philippe Bekaert
> Op 14 jun. 2022 om 22:43 heeft David Kastrup <dak(a)gnu.org> het volgende
geschreven:
>
> "Chris Caudle" <6807.chris(a)pop.powweb.com> writes:
>
>>>> On Tue, June 14, 2022 1:04 pm, Philippe Bekaert wrote:
>>>> Dante: merging technologies has an open source software aes67 driver for
>>>> Linux. However, the user space configuration tool is closed source.
>>
>> Merging developers do not keep the driver up to date with changing kernel
>> requirements. The Merging driver does not compile with the last year or
>> more of kernel versions, but Andrea Bondavalli has created some patches
>> which allow the driver to build with the latest kernels, as well as a GPL
>> user space daemon to replace the closed source Merging tool.
>>
>> https://github.com/bondagit/
>>
>> If you download the AES67 daemon project it will download and build the
>> patched ravenna-alsa-driver into the "3rd party" subdirectory.
>
> Sort of annoying, given that Linux has been around for 30 years or so,
> powers _all_ of the top 100 supercomputers (last time I looked) and is
> the most installed kernel in the world (Android uses it). Still, nobody
> feels there is a point in supporting it. Well ok, Intel GPU support
> tends to be comparatively useful. And the class-compliant part of
> class-compliant devices tends to work.
>
> But somehow that's not all too different from the state 20 years ago.
>
> --
> David Kastrup
> _______________________________________________
> Linux-audio-user mailing list
> Linux-audio-user(a)lists.linuxaudio.org
> https://lists.linuxaudio.org/listinfo/linux-audio-user
3:35 a.m.
Talking about audio on Linux, things are not perfect
on the Linux side
either. There is some good documentation, eg, but audio on
platforms like
macOS is considerably better documented.
I would say that this is incorrect. macOS audio looks extremely well
documented. Then you find you actually need it, and it is the only source
of "canonical" information, and it is either wrong, inadequate or
misleading. The macOS API surface is gigantic (comparable to a combination
of ALSA, GStreamer, JACK, and more), and the documentation appears much
more extensive than it actually is.
On Tue, Jun 14, 2022 at 3:37 PM Philippe Bekaert <linux(a)panokkel.be> wrote:
> I’m not that pessimistic. I’m often programming against frame grabber and
> Sdi cards, and even though not everything is fully open source (a lot is),
> I find there is considerable support for Linux. More so than in the past.
> Some companies do not, but you can do without them.
>
> Companies like rme apparently do not have much resources for doing their
> own Linux driver development but they really are helpful to those who want
> to do. On the other hand, they do have an edge wrt competition and are
> reluctant indeed to give out certain information that you really would love
> to use.
>
Talking about audio on Linux, things are not perfect
on the Linux side
> either. There is some good documentation, eg, but audio on
platforms like
> macOS is considerably better documented. The Linux adagium that the source
> code is the ultimate documentation, is not that widely accepted outside the
> Linux universe. Though I have 40 years of experience with c, and was a
> Linux user since 91, I’m often scratching my head studying the alsa driver
> core. It’s really not so easy …
>
> Best, ph
>
> Philippe Bekaert
>
> > Op 14 jun. 2022 om 22:43 heeft David Kastrup <dak(a)gnu.org> het volgende
> geschreven:
> >
> > "Chris Caudle" <6807.chris(a)pop.powweb.com> writes:
> >
> >>> On Tue, June 14, 2022 1:04 pm, Philippe Bekaert wrote:
> >>> Dante: merging technologies has an open source software aes67 driver
> for
> >>> Linux. However, the user space configuration tool is closed source.
> >>
> >> Merging developers do not keep the driver up to date with changing
> kernel
> >> requirements. The Merging driver does not compile with the last year or
> >> more of kernel versions, but Andrea Bondavalli has created some patches
> >> which allow the driver to build with the latest kernels, as well as a
> GPL
> >> user space daemon to replace the closed source Merging tool.
> >>
> >> https://github.com/bondagit/
> >>
> >> If you download the AES67 daemon project it will download and build the
> >> patched ravenna-alsa-driver into the "3rd party" subdirectory.
> >
> > Sort of annoying, given that Linux has been around for 30 years or so,
> > powers _all_ of the top 100 supercomputers (last time I looked) and is
> > the most installed kernel in the world (Android uses it). Still, nobody
> > feels there is a point in supporting it. Well ok, Intel GPU support
> > tends to be comparatively useful. And the class-compliant part of
> > class-compliant devices tends to work.
> >
> > But somehow that's not all too different from the state 20 years ago.
> >
> > --
> > David Kastrup
> > _______________________________________________
> > Linux-audio-user mailing list
> > Linux-audio-user(a)lists.linuxaudio.org
> > https://lists.linuxaudio.org/listinfo/linux-audio-user
> _______________________________________________
> Linux-audio-user mailing list
> Linux-audio-user(a)lists.linuxaudio.org
> https://lists.linuxaudio.org/listinfo/linux-audio-user
>
2:22 p.m.
I’m definitely not advocating mac over Linux… but my experience is that Linux audio
programming at driver/alsa level really could be easier give more extensive documentation
(which I’m willing to contribute to, btw). Documentation is key to get work done in
industry. At least, Linux has the huge benefit that the source code is there, so one has
“true” source of info, but some more documentation here and there, in or out of the source
code, would really help. I do have a couple of issues I failed to solve myself so far
(such as finding a decent way to pass hardware sample counters to user programs in a
reliable way), even though I’m really trained at studying other persons software. For you,
who grew up with the development of alsa, and who contributed so significantly to it, you
have a lot of background that latecomers like me (I’m doing Linux audio since a couple of
years only), are missing. Much info is in the lad archives, I know, but they are huge and
difficult to search. This is definitely not meant to start a flame war or so - but I felt
it was a good time to bring up this difficulty I experience. And which I believe could be
a serious hindrance to audio hardware manufacturers in supporting Linux.
Best, ph
Philippe Bekaert
Op 15 jun. 2022 om 01:35 heeft Paul Davis
<paul(a)linuxaudiosystems.com> het volgende geschreven:
Talking about audio on Linux, things are not
perfect on the Linux side either. There is some good documentation, eg, but audio on
platforms like macOS is considerably better documented.
I would say that this is incorrect. macOS audio looks extremely well documented. Then you
find you actually need it, and it is the only source of "canonical" information,
and it is either wrong, inadequate or misleading. The macOS API surface is gigantic
(comparable to a combination of ALSA, GStreamer, JACK, and more), and the documentation
appears much more extensive than it actually is.
> On Tue, Jun 14, 2022 at 3:37 PM Philippe Bekaert <linux(a)panokkel.be> wrote:
> I’m not that pessimistic. I’m often programming against frame grabber and Sdi cards,
and even though not everything is fully open source (a lot is), I find there is
considerable support for Linux. More so than in the past. Some companies do not, but you
can do without them.
>
> Companies like rme apparently do not have much resources for doing their own Linux
driver development but they really are helpful to those who want to do. On the other hand,
they do have an edge wrt competition and are reluctant indeed to give out certain
information that you really would love to use.
>
> Talking about audio on Linux, things are not perfect on the Linux side either. There
is some good documentation, eg, but audio on platforms like macOS is considerably better
documented. The Linux adagium that the source code is the ultimate documentation, is not
that widely accepted outside the Linux universe. Though I have 40 years of experience with
c, and was a Linux user since 91, I’m often scratching my head studying the alsa driver
core. It’s really not so easy …
>
> Best, ph
>
> Philippe Bekaert
>
> > Op 14 jun. 2022 om 22:43 heeft David Kastrup <dak(a)gnu.org> het volgende
geschreven:
> >
> > "Chris Caudle" <6807.chris(a)pop.powweb.com> writes:
> >
> >>> On Tue, June 14, 2022 1:04 pm, Philippe Bekaert wrote:
> >>> Dante: merging technologies has an open source software aes67 driver
for
> >>> Linux. However, the user space configuration tool is closed source.
> >>
> >> Merging developers do not keep the driver up to date with changing kernel
> >> requirements. The Merging driver does not compile with the last year or
> >> more of kernel versions, but Andrea Bondavalli has created some patches
> >> which allow the driver to build with the latest kernels, as well as a GPL
> >> user space daemon to replace the closed source Merging tool.
> >>
> >> https://github.com/bondagit/
> >>
> >> If you download the AES67 daemon project it will download and build the
> >> patched ravenna-alsa-driver into the "3rd party" subdirectory.
> >
> > Sort of annoying, given that Linux has been around for 30 years or so,
> > powers _all_ of the top 100 supercomputers (last time I looked) and is
> > the most installed kernel in the world (Android uses it). Still, nobody
> > feels there is a point in supporting it. Well ok, Intel GPU support
> > tends to be comparatively useful. And the class-compliant part of
> > class-compliant devices tends to work.
> >
> > But somehow that's not all too different from the state 20 years ago.
> >
> > --
> > David Kastrup
> > _______________________________________________
> > Linux-audio-user mailing list
> > Linux-audio-user(a)lists.linuxaudio.org
> > https://lists.linuxaudio.org/listinfo/linux-audio-user
> _______________________________________________
> Linux-audio-user mailing list
> Linux-audio-user(a)lists.linuxaudio.org
> https://lists.linuxaudio.org/listinfo/linux-audio-user
5:04 p.m.
Don't misunderstand me. I would never claim that ALSA is well documented,
certainly not for device driver authors. I was just pushing back on the
idea that the situation on macOS is much better. It *looks* better, but
looks can be deceiving.
On Wed, Jun 15, 2022 at 4:22 AM Philippe Bekaert <linux(a)panokkel.be> wrote:
I’m definitely not advocating mac over Linux… but my
experience is that
Linux audio programming at driver/alsa level really could be easier give
more extensive documentation (which I’m willing to contribute to, btw).
Documentation is key to get work done in industry. At least, Linux has the
huge benefit that the source code is there, so one has “true” source of
info, but some more documentation here and there, in or out of the source
code, would really help. I do have a couple of issues I failed to solve
myself so far (such as finding a decent way to pass hardware sample
counters to user programs in a reliable way), even though I’m really
trained at studying other persons software. For you, who grew up with the
development of alsa, and who contributed so significantly to it, you have a
lot of background that latecomers like me (I’m doing Linux audio since a
couple of years only), are missing. Much info is in the lad archives, I
know, but they are huge and difficult to search. This is definitely not
meant to start a flame war or so - but I felt it was a good time to bring
up this difficulty I experience. And which I believe could be a serious
hindrance to audio hardware manufacturers in supporting Linux.
Best, ph
Philippe Bekaert
Op 15 jun. 2022 om 01:35 heeft Paul Davis <paul(a)linuxaudiosystems.com>
het volgende geschreven:
Talking about audio on Linux, things are not
perfect on the Linux side
either. There is some good documentation, eg, but audio
on platforms like
macOS is considerably better documented.
I would say that this is incorrect. macOS audio looks extremely well
documented. Then you find you actually need it, and it is the only source
of "canonical" information, and it is either wrong, inadequate or
misleading. The macOS API surface is gigantic (comparable to a combination
of ALSA, GStreamer, JACK, and more), and the documentation appears much
more extensive than it actually is.
On Tue, Jun 14, 2022 at 3:37 PM Philippe Bekaert <linux(a)panokkel.be>
wrote:
I’m not that pessimistic. I’m often programming
against frame grabber and
Sdi cards, and even though not everything is fully open source (a lot is),
I find there is considerable support for Linux. More so than in the past.
Some companies do not, but you can do without them.
Companies like rme apparently do not have much resources for doing their
own Linux driver development but they really are helpful to those who want
to do. On the other hand, they do have an edge wrt competition and are
reluctant indeed to give out certain information that you really would love
to use.
Talking about audio on Linux, things are not perfect on the Linux side
either. There is some good documentation, eg, but audio on platforms like
macOS is considerably better documented. The Linux adagium that the source
code is the ultimate documentation, is not that widely accepted outside the
Linux universe. Though I have 40 years of experience with c, and was a
Linux user since 91, I’m often scratching my head studying the alsa driver
core. It’s really not so easy …
Best, ph
Philippe Bekaert
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-user
Op 14 jun. 2022 om 22:43 heeft David Kastrup
<dak(a)gnu.org> het
volgende geschreven:
"Chris Caudle" <6807.chris(a)pop.powweb.com> writes:
>> On Tue, June 14, 2022 1:04 pm, Philippe Bekaert wrote:
>> Dante: merging technologies has an open source software aes67 driver
for
>> Linux. However, the user space
configuration tool is closed source.
>
> Merging developers do not keep the driver up to date with changing
kernel
> requirements. The Merging driver does not
compile with the last year
or
> more of kernel versions, but Andrea
Bondavalli has created some patches
> which allow the driver to build with the latest kernels, as well as a
GPL
user
space daemon to replace the closed source Merging tool.
https://github.com/bondagit/
If you download the AES67 daemon project it will download and build the
patched ravenna-alsa-driver into the "3rd party" subdirectory.
Sort of annoying, given that Linux has been around for 30 years or so,
powers _all_ of the top 100 supercomputers (last time I looked) and is
the most installed kernel in the world (Android uses it). Still, nobody
feels there is a point in supporting it. Well ok, Intel GPU support
tends to be comparatively useful. And the class-compliant part of
class-compliant devices tends to work.
But somehow that's not all too different from the state 20 years ago.
--
David Kastrup
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-user
16 Jun
16 Jun
1:07 a.m.
Agree. Ph
Philippe Bekaert
Op 15 jun. 2022 om 15:03 heeft Paul Davis
<paul(a)linuxaudiosystems.com> het volgende geschreven:
Don't misunderstand me. I would never claim that ALSA is well documented, certainly
not for device driver authors. I was just pushing back on the idea that the situation on
macOS is much better. It *looks* better, but looks can be deceiving.
> On Wed, Jun 15, 2022 at 4:22 AM Philippe Bekaert <linux(a)panokkel.be> wrote:
> I’m definitely not advocating mac over Linux… but my experience is that Linux audio
programming at driver/alsa level really could be easier give more extensive documentation
(which I’m willing to contribute to, btw). Documentation is key to get work done in
industry. At least, Linux has the huge benefit that the source code is there, so one has
“true” source of info, but some more documentation here and there, in or out of the source
code, would really help. I do have a couple of issues I failed to solve myself so far
(such as finding a decent way to pass hardware sample counters to user programs in a
reliable way), even though I’m really trained at studying other persons software. For you,
who grew up with the development of alsa, and who contributed so significantly to it, you
have a lot of background that latecomers like me (I’m doing Linux audio since a couple of
years only), are missing. Much info is in the lad archives, I know, but they are huge and
difficult to search. This is definitely not meant to start a flame war or so - but I felt
it was a good time to bring up this difficulty I experience. And which I believe could be
a serious hindrance to audio hardware manufacturers in supporting Linux.
>
> Best, ph
>
> Philippe Bekaert
>
>>> Op 15 jun. 2022 om 01:35 heeft Paul Davis <paul(a)linuxaudiosystems.com>
het volgende geschreven:
>>>
>>
>> > Talking about audio on Linux, things are not perfect on the Linux side
either. There is some good documentation, eg, but audio on platforms like macOS is
considerably better documented.
>>
>> I would say that this is incorrect. macOS audio looks extremely well documented.
Then you find you actually need it, and it is the only source of "canonical"
information, and it is either wrong, inadequate or misleading. The macOS API surface is
gigantic (comparable to a combination of ALSA, GStreamer, JACK, and more), and the
documentation appears much more extensive than it actually is.
>>
>>> On Tue, Jun 14, 2022 at 3:37 PM Philippe Bekaert <linux(a)panokkel.be>
wrote:
>>> I’m not that pessimistic. I’m often programming against frame grabber and Sdi
cards, and even though not everything is fully open source (a lot is), I find there is
considerable support for Linux. More so than in the past. Some companies do not, but you
can do without them.
>>>
>>> Companies like rme apparently do not have much resources for doing their own
Linux driver development but they really are helpful to those who want to do. On the other
hand, they do have an edge wrt competition and are reluctant indeed to give out certain
information that you really would love to use.
>>>
>>> Talking about audio on Linux, things are not perfect on the Linux side
either. There is some good documentation, eg, but audio on platforms like macOS is
considerably better documented. The Linux adagium that the source code is the ultimate
documentation, is not that widely accepted outside the Linux universe. Though I have 40
years of experience with c, and was a Linux user since 91, I’m often scratching my head
studying the alsa driver core. It’s really not so easy …
>>>
>>> Best, ph
>>>
>>> Philippe Bekaert
>>>
>>> > Op 14 jun. 2022 om 22:43 heeft David Kastrup <dak(a)gnu.org> het
volgende geschreven:
>>> >
>>> > "Chris Caudle" <6807.chris(a)pop.powweb.com> writes:
>>> >
>>> >>> On Tue, June 14, 2022 1:04 pm, Philippe Bekaert wrote:
>>> >>> Dante: merging technologies has an open source software aes67
driver for
>>> >>> Linux. However, the user space configuration tool is closed
source.
>>> >>
>>> >> Merging developers do not keep the driver up to date with changing
kernel
>>> >> requirements. The Merging driver does not compile with the last
year or
>>> >> more of kernel versions, but Andrea Bondavalli has created some
patches
>>> >> which allow the driver to build with the latest kernels, as well as
a GPL
>>> >> user space daemon to replace the closed source Merging tool.
>>> >>
>>> >> https://github.com/bondagit/
>>> >>
>>> >> If you download the AES67 daemon project it will download and build
the
>>> >> patched ravenna-alsa-driver into the "3rd party"
subdirectory.
>>> >
>>> > Sort of annoying, given that Linux has been around for 30 years or so,
>>> > powers _all_ of the top 100 supercomputers (last time I looked) and is
>>> > the most installed kernel in the world (Android uses it). Still,
nobody
>>> > feels there is a point in supporting it. Well ok, Intel GPU support
>>> > tends to be comparatively useful. And the class-compliant part of
>>> > class-compliant devices tends to work.
>>> >
>>> > But somehow that's not all too different from the state 20 years
ago.
>>> >
>>> > --
>>> > David Kastrup
>>> > _______________________________________________
>>> > Linux-audio-user mailing list
>>> > Linux-audio-user(a)lists.linuxaudio.org
>>> > https://lists.linuxaudio.org/listinfo/linux-audio-user
>>> _______________________________________________
>>> Linux-audio-user mailing list
>>> Linux-audio-user(a)lists.linuxaudio.org
>>> https://lists.linuxaudio.org/listinfo/linux-audio-user
4:02 p.m.
On Tue, Jun 14, 2022 at 11:36:57PM +0200, Philippe Bekaert wrote:
Though I have 40 years of experience with c, and was a
Linux user since 91,
I’m often scratching my head studying the alsa driver core. It’s really not
so easy …
Not only driver code, the user space API docs have the same problem, and
it's a common one with doxygen generated 'documentation'.
Have a look at
<https://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m___s_w___params.html>
'Set period event inside a software configuration container.'
'Set silence size inside a software configuration container.'
'Set silence threshold inside a software configuration container.'
etc. etc.
None of these descriptions tell you anything you wouldn't know from
the actual function name. They are completely useless.
But *nowhere* (AFAIK) it is explained what a 'period event' is, or
why I should bother to set a 'silence threshold' or 'silence size'.
You could as well try to learn a new language given only a dictionary.
Ciao,
--
FA
4:24 p.m.
Fons Adriaensen <fons(a)linuxaudio.org> writes:
On Tue, Jun 14, 2022 at 11:36:57PM +0200, Philippe
Bekaert wrote:
You could call it a perversion of Donald Knuth's concept of "Literate
Programming" which presents a program as an essay, with the program code
embedded into the overarching documentation in a cohesive order.
You just leave off the overarching documentation and the program code
and the cohesive order. It's sort of like serving a hard-boiled egg for
an order of soufflée. Same thing except for a lack of structure.
--
David Kastrup
Though I have 40 years of experience with c, and
was a Linux user since 91,
I’m often scratching my head studying the alsa driver core. It’s really not
so easy …
Not only driver code, the user space API docs have the same problem, and
it's a common one with doxygen generated 'documentation'.
Have a look at
<https://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m___s_w___params.html>
'Set period event inside a software configuration container.'
'Set silence size inside a software configuration container.'
'Set silence threshold inside a software configuration container.'
etc. etc.
None of these descriptions tell you anything you wouldn't know from
the actual function name. They are completely useless.
But *nowhere* (AFAIK) it is explained what a 'period event' is, or
why I should bother to set a 'silence threshold' or 'silence size'.
You could as well try to learn a new language given only a dictionary.
5:39 p.m.
On Thu, Jun 16, 2022 at 02:24:13PM +0200, David Kastrup wrote:
You could call it a perversion of Donald Knuth's
concept of "Literate
Programming" which presents a program as an essay, with the program code
embedded into the overarching documentation in a cohesive order.
I read his book ages ago (and still have a copy), but I don't agree
with all of it. There are two very different things that need docs:
1. The algorithm used, or the intended workings of the system that
is controlled by an API,
2. The actual implementation.
(2) can be mixed with the code - it is what you need for maintaining
the code, fix bugs, etc.
(1) has aspects that could be mixed with the code in simple cases,
but in general this should be some form of design document. It should
make clear what the code is supposed to do and how, or what exactly
the API is supposed to control and how. And at least it should define
all the terminology used in (1) and in the code itself.
For any API there will be an underlying 'model' of what is actually
controlled by that API. This is the missing part for the ALSA libs.
There is also (0) - domain specific knowledge. You may expect a
user to have this - there should be no need to explain what 'PCM'
means in the ALSA docs.
But expect a disaster if code is written by an author who doesn't
have the necessary background, just from some formal specification,
unless those specs are written and the code is reviewed by someone
with domain-specific knowledge. But that is a different problem.
Ciao,
--
FA
5:54 p.m.
Fons Adriaensen <fons(a)linuxaudio.org> writes:
On Thu, Jun 16, 2022 at 02:24:13PM +0200, David
Kastrup wrote:
Well, it would be kind of unrealistic to expect a trailblazer to find
the best of all possible trajectories. I am perfectly willing to credit
a large contribution to the state of art without feeling the need to
call it perfect.
It's just depressing that quite a few future implementations/concepts in
its wake are actually regressions in major respects.
Knuth was willing to do what it takes to make his concept and tools work
for a particular program/implementation. Of course that makes a
difference and makes for a good proof of concept.
How the like of doxygen are employed in the field is partly more a
counterproof of concept. Either way not all of the blame or praise
rests with the tool but rather the user's determination to actually make
it work for its purpose.
--
David Kastrup
You could call it a perversion of Donald
Knuth's concept of "Literate
Programming" which presents a program as an essay, with the program code
embedded into the overarching documentation in a cohesive order.
I read his book ages ago (and still have a copy), but I don't agree
with all of it.
10:50 p.m.
I don’t think doxygen or the like used in the kernel source is the main issue. It’s just
that documentation isn’t written beyond evident rephrasings of function names and
arguments as you say. It’s perfectly possible and practical to provide documentation of
type 1 and 2 in the source files themselves, and maintain it there. And of course everyone
touching the Linux audio sources has the necessary domain knowledge.
Other issue is that much of the current documentation (eg alsa project site) seems to be
terribly outdated.
As said, I’m willing to contribute to documenting, if someone else (senior) takes a lead.
I believe it could be a serious boost for Linux audio, especially pro.
Best, ph
Philippe Bekaert
Op 16 jun. 2022 om 15:56 heeft David Kastrup
<dak(a)gnu.org> het volgende geschreven:
Fons Adriaensen <fons(a)linuxaudio.org> writes:
Well, it would be kind of unrealistic to expect a trailblazer to find
the best of all possible trajectories. I am perfectly willing to credit
a large contribution to the state of art without feeling the need to
call it perfect.
It's just depressing that quite a few future implementations/concepts in
its wake are actually regressions in major respects.
Knuth was willing to do what it takes to make his concept and tools work
for a particular program/implementation. Of course that makes a
difference and makes for a good proof of concept.
How the like of doxygen are employed in the field is partly more a
counterproof of concept. Either way not all of the blame or praise
rests with the tool but rather the user's determination to actually make
it work for its purpose.
--
David Kastrup
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-user
On Thu,
Jun 16, 2022 at 02:24:13PM +0200, David Kastrup wrote:
You could call it a perversion of Donald Knuth's concept of "Literate
Programming" which presents a program as an essay, with the program code
embedded into the overarching documentation in a cohesive order.
I read his book ages ago (and still have a copy), but I don't agree
with all of it.
17 Jun
17 Jun
2:35 a.m.
On Thu, Jun 16, 2022 at 08:50:24PM +0200, Philippe Bekaert wrote:
I don’t think doxygen or the like used in the kernel
source is the main issue.
I agree. It is perfectly possible to provide good docs with or without doxygen.
What seems to happen regularly is that doxygen is used as a smoke screen to
make the documenation look OK while it is actually useless - 'nobody was ever
fired for using doxygen'.
And of course everyone touching the Linux audio
sources has the necessary
domain knowledge.
Probably. That is not the case in the commercial world where it is often
assumed that any programmer can produce good code just given some formal
specifications, even if the coder doen't understand what it's all about.
As said, it's a different problem.
Ciao,
--
FA
2:10 a.m.
* David Kastrup <dak(a)gnu.org> [2022-06-14 19:21]:
[...]
It's sort of embarrassing but the Hammerfall DSP
cards work with either
the Expresscard adapter or an Expresscard-to-Cardbus adapter (the latter
_has_ to map the PCI express lane of the Expresscard slot, not the USB
lane) with the old Cardbus adapter. It's ancient technology with 8
line-in/line-out connectors and quite robust ADAT support, but in terms
of the quality and latency of the available connections and driver
support, it's still unprecedented.
The Expresscard-to-Cardbus adapter solution is not overly convincing
mechanically. And you need to dig up the firmware for 64bit versions of
Linux (no idea where I got my .deb from when I needed to upgrade).
Isn't it in
alsa-firmware-loaders package? Or does it ship without the
actual firmware?
And of course, Expresscard slots are a dying breed as
well.
I am still using two Lenovo X230s for live work. They are amongst the
last laptops from this manufacturer with an ExpressCard slot. I think I
have earned a part of my living with an RME HDSP+Multiface for the last
twenty years. About three weeks ago the card cause a hard lockup of my
laptop in one of the last rehearsals for a concert which would require
it to work together with a 20 member ensemble in front of a 300+
audience. Had to replace it temporarily with a Motu B16.
I had multiple problems with this RME card: Firmware would not load
randomly, or the card would be detected being connected to a digiface
with wrong firmware loading also randomly. In terms of features, quality
and latency this is amongst the best linux laptop cards. I think I have
to let it go after 20+ years now.
best, P
2:55 a.m.
"Peter P." <peterparker(a)fastmail.com> writes:
Downgrading the Expresscard version/speed in the BIOS might or might not
help. Can you guess whether the problem is more likely with the
interface card (I assume the expresscard version rather than the
adapter/Pccard stack I use) or the Multiface breakout box?
--
David Kastrup
* David Kastrup <dak(a)gnu.org> [2022-06-14
19:21]:
[...]
The latter. I think I got the 64bit .deb from Medibuntu when that was
still a thing.
It's sort of embarrassing but the Hammerfall
DSP cards work with either
the Expresscard adapter or an Expresscard-to-Cardbus adapter (the latter
_has_ to map the PCI express lane of the Expresscard slot, not the USB
lane) with the old Cardbus adapter. It's ancient technology with 8
line-in/line-out connectors and quite robust ADAT support, but in terms
of the quality and latency of the available connections and driver
support, it's still unprecedented.
The Expresscard-to-Cardbus adapter solution is not overly convincing
mechanically. And you need to dig up the firmware for 64bit versions of
Linux (no idea where I got my .deb from when I needed to upgrade).
Isn't it in
alsa-firmware-loaders package? Or does it ship without the
actual firmware? And of course, Expresscard slots are a dying
breed as well.
I am still using two Lenovo X230s for live work. They are amongst the
last laptops from this manufacturer with an ExpressCard slot. I think I
have earned a part of my living with an RME HDSP+Multiface for the last
twenty years. About three weeks ago the card cause a hard lockup of my
laptop in one of the last rehearsals for a concert which would require
it to work together with a 20 member ensemble in front of a 300+
audience. Had to replace it temporarily with a Motu B16.
I had multiple problems with this RME card: Firmware would not load
randomly, or the card would be detected being connected to a digiface
with wrong firmware loading also randomly. In terms of features, quality
and latency this is amongst the best linux laptop cards. I think I have
to let it go after 20+ years now.
3:05 a.m.
* David Kastrup <dak(a)gnu.org> [2022-06-17 00:55]:
[...]
The latter. I think I got the 64bit .deb from Medibuntu when that was
still a thing. Check the package's readme on Debian
https://packages.debian.org/bullseye/amd64/alsa-firmware-loaders/filelist
It mentions an install location and I actually have the file
/lib/firmware/multiface_firmware_rev11.bin
there...
[...]
Thank you, do you know
the Expresscard version and speed can be set in
Lenovo X230 Bios? The probelm I decribed is a card that loads fine,
jackd starts fine and completely locks up my laptop after about two
hours of continuous use (short before an upcoming show).
best, P
And you need to dig up the firmware for 64bit versions
of
Linux (no idea where I got my .deb from when I needed to upgrade).
Isn't it in
alsa-firmware-loaders package? Or does it ship without the
actual firmware? I think I
have
to let it go after 20+ years now.
Downgrading the Expresscard version/speed in the BIOS might or might not
help. Can you guess whether the problem is more likely with the
interface card (I assume the expresscard version rather than the
adapter/Pccard stack I use) or the Multiface breakout box?
884
days inactive
889
days old
linux-audio-user@lists.linuxaudio.org
31 comments
11 participants
participants (11)
-
Anders Hellquist -
Brandon Hale -
Chris Caudle -
Christopher Arndt -
David Kastrup -
Fons Adriaensen -
Jeanette C. -
Michael Zoet -
Paul Davis -
Peter P. -
Philippe Bekaert