Hi Eliot,

Thanks for your response, but I think that is a very poor solution. Jack is problematic on many configurations, and I have no intention of modifying this app to rely on Jack Transport or any Jack session manager in order to play nicely with the rest of the Jack ecosystem, nor do Jack's features add value to my application. Therefore, it makes little sense to use Jack or accept it's additional bugs and CPU overhead, no more than it makes sense to use Pulseaudio for high performance, low latency audio applications, adding another layer over ALSA can only result in more bugs and more overhead, not less.

Surely an experienced core ALSA developer could create such a demo of how the API is meant to be used in less than an hour. This would save numerous ALSA-curious developers like myself countless hours of reverse engineering other applications and scouring alsa-devel mailing list posts attempting to understand how ALSA is meant to be used. I understand that writing documentation isn't fun, but after my first 2 weeks of trying I have to believe that countless developers have probably given up on ALSA (and Linux by extension) due to the cryptic documentation and lack of simplest-case example code. With the example I proposed, I could've been productive from day one.

Thanks, Carl

On Tue, Sep 3, 2013 at 8:58 PM, Eliot Blennerhassett < eliot@blennerhassett.gen.nz> wrote:

On 04/09/13 12:32, Carl Canuck wrote:

...

especially for one of the most important use-cases of all: the full on digital audio

workstation.

The stock answer for this use case is "Don't use ALSA directly; use JACK" http://jackaudio.org/

Carl,

Thanks for your response, but I think that is a very poor solution. [ignorant blah]

Surely an experienced core ALSA developer could create such a demo [more blah]

How about: You write the documentation, given your 'fresh' experience with ALSA to help others in your situation.

Or even better: Accept recommendations from other developers and use jack. You would have finished after half an hour and your application would cooperate with all other audio applications.

All you have now is two wasted weeks of your life span and a non-cooperative application. And other new ALSA users are still in the same situation as you were.

Flo

2013/9/4 Carl Canuck carl.canuck.official@gmail.com

Ignorant? You do realize that Jack has captured the hearts and minds of exactly zero world renowned audio professionals, despite being "professional grade" according to it's developers? Do you think that could possibly be a problem with Jack, or did everybody just not give it enough of a chance?

If you insist on using pure ALSA: Read the docs that Grant pointed you to. Everything you need is there, IMO. Otherwise, using portaudio/portmidi can help you in porting your Windows application to Linux. The tool of choice though is: Err, you just don't want to hear that again...

Why the hell should somebody with no experience programming with ALSA attempt to reverse-engineer, document and create example code when the only references available are some horribly inadequate API docs and a few kernels of wisdom scattered over years of mailing lists?

Ever so often, once you figured something out you can't see your initial problems in understanding anymore. That's why it is a good idea to write about such things as long as you still see your problems.

BTW, I can't see anything missing in the example code that would be relevant to you. So what's wrong with it? What's wrong with the API docs? It's a bit rough, sure. But it's your decision to go the hard way and not use the adequate tool for your problem.

I think instead I'll just abandon my attempts to port anything to Linux if the attitude of the ALSA community is that the combined use of ALSA audio and MIDI with proper device configuration options is supposed to be a big secret that you all are too busy to share.

You asked for advice. You got advice. You don't like the advice. You complain. Hmmm. Doesn't sound right to me.

Continue the conversation if you choose, but I am searching for the unsubscribe button as we speak.

I have no incentive to port anything to Linux other than some general feelings of goodwill towards the open source community. If you truly feel that writing a kludgy API with poor documentation and example code that's only meant to be wrapped into other APIs developed by those brave souls willing to take the time to reverse engineer it all is good business, then by all means keep on doing what you're doing. It is my personal conviction that I would much rather retain full control of my application by communicating directly with ALSA rather than delegating control to Jack just to ease the pain of deciphering your poor documentation.

I am truly sorry for taking time away from your driver development, please continue with your work and let this conversation die in peace, I will not be participating in this conversation or your mailing list any further.

On Wed, Sep 4, 2013 at 10:05 AM, Clemens Ladisch clemens@ladisch.de wrote:

Carl Canuck wrote:

...

if the attitude of the ALSA community is

There is no individual that has the power to speak for the community.

Regards, Clemens _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

On Wednesday 04 Sep 2013 09:20:23 Carl Canuck wrote:

...

Thanks for your response, but I think that is a very poor solution. [ignorant blah]

Ignorant? You do realize that Jack has captured the hearts and minds of exactly zero world renowned audio professionals, despite being "professional grade" according to it's developers?

You do realise that native ALSA music production apps have captured an even smaller number of those hearts and minds...

And of the many people who do use Linux for music production (professional or otherwise), native ALSA apps have captured very close to zero percent of their hearts and minds.

Amongst the Linux audio production market Jack is, far and away, the most popular approach both amongst app developers and users. It is the de-facto standard. Part of this is because Jack enables your app to work well with others, whereas ALSA on it's own does not.

If you want people in this market to use your app, then you shouldn't even be considering not using Jack.

Unless, of course, you are trying to consign your app to obscurity to give you another reason to denigrate Linux and it's users.

Do you think that could possibly be a problem with Jack, or did everybody just not give it enough of a chance?

Have you considered that it could be other factors, such as Linux only having a few percent of the desktop market (where audio production sits) or that none of the "brand name" software vendors produce software for it, or that people in that industry are not generally very computer-literate and may not have even heard of Linux, yet alone know you could produce music on it or are willing to take the risk on using a new, unknown platform.

All of the above are good reasons. I have worked with ALSA and Jack for several years and you are the only person in this time I have heard suggest the root cause for lack of Linux penetration in the audio production market is due to Jack. It's a crazy suggestion and, unless you have some firm evidence backing this up, ignorance really is the only explanation for such a suggestion.

In looking to write a native ALSA music production app you were on completely the wrong path. This community has, generously, offered you advice to steer you onto the correct path. I recommend you swallow your pride, and follow this sage advice.

Cheers,

Keith