15 Jun
2022
15 Jun
'22
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