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