On Tue, Feb 19, 2013 at 05:24:29PM +0000, Richard Fitzgerald wrote:
I am fine with adding new API for returning the samples, but then why return the raw struct. Would make sense to just get samples if that is only thing desired.
Is there a need to hide the underlying ALSA structs from a client of tinyalsa? If so, why?
The user shouldnt care what struct ALSA is using. One needs to know the timeline or samples and you provide them without worrying about what is underlying representation.
Might other fields in snd_compr_tstamp be useful to the client? If so it's cleaner to just return them all instead of having to spawn several different functions the client has to call to get a snd_compr_tstamp and then return each field separately.
For now I see use of samples, time and offset value in ring buffer. But yes it depends on how you wrote the clinet and what are you going to do with these values. The kernel represenattion is genric.
If snd_compr_tstamp is basically useless to any tinycompress client except for the value of pcm_io_frames (and maybe sampling_rate?) then I'm ok with just returning those instead of the raw snd_compr_tstamp.
Again, depends on how you wrote the client. You cna do some smart decisions based on how much DSP has fetched, decoded , rendered...
-- ~Vinod