would it be hard to provide the backward compatibility via a user fs -- at least until apps are updated to the new structure?
On Wed, Oct 27, 2010 at 11:58 AM, Anthony Sorace <a...@9srv.net> wrote: > I've misplaced my USB audio kit, but I'm reasonably sure I read from > /dev/audio (and a cursory reading of the source suggests that ought to work). > Is there any reason to do otherwise? I don't know what audioin is intended to > buy. Given that it's never been in audio(3), I'm not sure it's important to > support it. > > It's unfortunate that volume and audioctl don't support the same language. > Don't add another. It's pretty easy to handle both; see > /sys/src/cmd/usb/audio/audiofs.c. The one for audioctl is reasonably regular > and comprehensive; it'd be nice to standardize our audio interfaces around > that. > > I'm more interested in audiostat. I don't see that in the usb implementation, > and I'm not clear on whether it could be provided there. Anyone know? Should > audio programs treat that as optional? > > "deprecation" in unix is a mess, where things can stay "deprecated" for ages. > it'd be nice to be able to say "/dev/volume (or /dev/eia0status) was a > mistake; here's a backwards-compatible improvement, and the old stuff goes > away in 6 months." > >