On Aug 11, 2009, at 10:43 PM, Anthony Sorace wrote:
Tim Newsham<news...@lava.net> wrote:
// Yah, this format doesnt come up that often.. perhaps its not
// worth the effort, but then again the ability to switch a device's
// encoding isnt very much work either... About as hard as
// changing the sampling rate or turning stereo on and off...
i'd argue that the primary cost is not the effort (of writing a
decoder vs. driving the
encoder to accept a different format), but the impact on the design.
being able to
say "this takes pcm" is a win.
When I was toying with FFmpeg, I had this idea, that perhaps my
initial pull model (where an external application needs to pull raw
data from /n/ffmpeg and play it back either in rio window or over
the speakers) was flawed and the better model would be it push
model (where we would simply use a filter filesystem over an
existing raw device).
In fact, perhaps even the page(1) command is falwed. What should've
happened was a next layer over rio, where /dev/draw/n/data would
be able to accept any kind of image encoding.
my main question comes from "fancy" formats. on cards that do 5.1,
for example,
do we simply write 6-channel pcm samples in a defined order? i have
no idea how
the cards behave in this regard. if it requires more than that (say,
write ac-3
directly), i'd suggest that's not /dev/audio.
With multichannel playback you have those two options:
1. drive each channel separately with PCM
2. do AC-3/DTC/MP3 passthrough
For audio recording it is mostly multichannel.
Thanks,
Roman.
