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@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@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@gnu.org> het volgende geschreven:
>
> "Chris Caudle" <6807.chris@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@lists.linuxaudio.org
> https://lists.linuxaudio.org/listinfo/linux-audio-user
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-user