Thread (28 messages) flat view 28 messages, 5 authors, 2024-08-14

Re: [RFC PATCH 1/6] ALSA: compress: add Sample Rate Converter codec support

From: Pierre-Louis Bossart <hidden>
Date: 2024-08-09 19:20:45
Also in: alsa-devel, linux-sound, lkml

quoted
quoted
And metadata
ioctl can be called many times which can meet the ratio modifier
requirement (ratio may be drift on the fly)
Interesting, that's yet another way of handling the drift with userspace
modifying the ratio dynamically. That's different to what I've seen
before.
Note that the "timing" is managed by the user space with this scheme.
quoted
quoted
And compress API uses codec as the unit for capability query and
parameter setting,  So I think need to define "SND_AUDIOCODEC_SRC'
and 'struct snd_dec_src',  for the 'snd_dec_src' just defined output
format and output rate, channels definition just reuse the
snd_codec.ch_in.
The capability query is an interesting point as well, it's not clear how
to expose to userspace what this specific implementation can do, while
at the same time *requiring* userpace to update the ratio dynamically.
For something like this to work, userspace needs to have pre-existing
information on how the SRC works.
Yes, it's about abstraction. The user space wants to push data, read
data back converted to the target rate and eventually modify the drift
using a control managing clocks using own way. We can eventually assume,
that if this control does not exist, the drift cannot be controlled.
Also, nice thing is that the control has min and max values (range), so
driver can specify the drift range, too.
This mode of operation would be fine, but if you add the SRC as part of
the processing allowed in a compressed stream, it might be used in a
'regular' real-time pipeline and the arguments  and implementation could
be very different.

In other words, this SRC support looks like an extension of the compress
API for a very narrow usage restricted to the memory-to-memory case
only. I worry a bit about the next steps... Are there going to be other
types of PCM processing like this, and if yes, how would we know if they
are intended to be used for the 'regular' compress API or for the
memory-to-memory scheme?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help