Re: [LAD] ALSA doumentation

Fred Gleason wrote:
> On Sunday 16 November 2008 04:16:19 pm you wrote:
>
>> Programmers are not stupid. However the way how typical sound
>> applications are implemented is wrong.
>>
>
> So this is a reason to cripple the API -- because 'typical'
> application programmers don't know what they're doing? What about
> those who *do*?
>
>
Programmers who know what they do don't do stupid things. All the
problems are caused by the programmers who *think* they know what they
do. They are so clever that they don't need to open any manuals, etc.
>> Network or disk performance analyzers/monitors/optimizers are good
>> tools. They are not "ordinary" applications but system tools.
>>
>
> Whatever the semantic difference between 'applications' and 'system
> tools' might be, *both* end up having to interact with the hardware
> via some sort of API, so I'm not sure that the distinction is
> particularly meaningful in this context.
>
Audio (or MIDI) applications produce and consume audio streams. All they
need to do is to tell what kind of stream (rate, format, etc) they want
to play/record. They can also adjust their input/output volume or select
the recording source if necessary. In this way the 'system tools' (or
any application dedicated for these purposes) can be used to route and
mix the

However if the application also tries to interact with the hardware (by
opening /dev/mixer in OSS or by doing similar things with ALSA) then
shit will happen. This kind of interaction with hardware may mean that
the application refuses to work with a pseudo/loopback device that hands
the signal directly to Icecast server. All this just because the
developer of the application wanted to add nice features to wrong place.

>
>> However it's wrong if programs like Mozilla try to do this kind of
>> functions.
>> All a web browser does is opening a TCP/IP socket to the
>> http/ftp/whatever server, sends the request and waits for the response.
>> Equally well an audio player application should just open a connection
>> to the audio device, set the rate/format and then just start to play.
>> They should not try to do things like automatic unmuting the sound card.
>>
>
> Right, but I think you're kind of missing the point. We're not
> talking about garden variety 'audio player' applications here. The
> world of audio -- especially professional audio -- is a much larger
> place. This doesn't make such applications 'system tools', merely
> applications that work outside of the simple assumptions adequate when
> designing garden-variety 'audio players'. To hardwire those simple
> assumptions into the driver system is IMO a design error, one that
> imposes serious limits on the usefulness of the overall system.
> Effectively, it's dictating policy in a layer that should be primarily
> concerned with mechanism.
>
Professional and professional. One definition of professional is
available in Wikipedia (http://en.wikipedia.org/wiki/Professional).
Audio professional is a professional specialized on audio. 'Professional
audio' is what audio professional does for living. Professionals use
hardware/software with much more features than ordinary users do.
Professionals indeed use HW/SW that has "professional features". However
they will not buy a (say) sampler that tries to reset the master mixing
console every time it's powered on.

On the other hand 'professional audio' is also a marketing term that
originates from popular _consumer_ sound cards such as Sound Blaster
Pro, Pro Audio Spectrum and many others. In this context "pro" means
that the device has all the bells and whistles. Usually there is also
loads of more or less useless bundled software included in the package.

So what kind of professional do you mean?

Best regards,

Hannu

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Mon Nov 17 16:15:02 2008