Re: ALSA API as standards

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Lennart Poettering wrote:
> Just a few random comments:
> 
> > /* I/O */
> > 
> > snd_input_stdio_open
> > snd_input_stdio_attach
> > snd_input_buffer_open
> > snd_input_close
> > snd_input_scanf
> > snd_input_gets
> > snd_input_getc
> > snd_input_ungetc
> > 
> > snd_output_stdio_open
> > snd_output_stdio_attach
> > snd_output_buffer_open
> > snd_output_buffer_string
> > snd_output_close
> > snd_output_printf
> > snd_output_vprintf
> > snd_output_puts
> > snd_output_putc
> > snd_output_flush
> 
> May I ask why these are exported at all? The seem to be some kind of
> STDOUT/STDIN abstraction, and have no place in a sound API I would
> say. Especially not in any "standardized" version of it.

The configuration code uses these functions to read and write .conf
files.

It might be useful for an application to have some private ALSA config
and to let ALSA read it from a file or from a string, but I don't think
this is something that belongs in LSB.

> > snd_pcm_dump
> > snd_pcm_dump_hw_setup
> > snd_pcm_dump_sw_setup
> > snd_pcm_dump_setup
> > snd_pcm_hw_params_dump
> > snd_pcm_sw_params_dump
> > snd_pcm_status_dump
> 
> And these? They are not even documented, or am I blind?

Well, their documentation isn't less useful than that of most other
functions.  ;-(

These functions are very valuable when debugging.  I wouldn't want to
discourage anybody from using them.

If we include these functions, we'll have to include some of the
snd_output_* functions.


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

[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux