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."
>
>

Reply via email to