[LAU] Multichannel analog I/O audio interface: experiences and tips

[Paul Davis]

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 at 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 at 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 at 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 at gnu.org> het
>> volgende geschreven:
>> >
>> > "Chris Caudle" <6807.chris at 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 at lists.linuxaudio.org
>> > https://lists.linuxaudio.org/listinfo/linux-audio-user
>> _______________________________________________
>> Linux-audio-user mailing list
>> Linux-audio-user at lists.linuxaudio.org
>> https://lists.linuxaudio.org/listinfo/linux-audio-user
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.linuxaudio.org/archives/linux-audio-user/attachments/20220615/d35f3049/attachment.html>