Hacker News new | ask | show | jobs
by djnliung 5255 days ago
I'm not sure that really contradicts his point, that's a terribly limited API. Stereo only, no way to specify channel layout, 16bit only, no way to change the device buffer sizes, no way to tell if the device is in use, no way to tell the device latency, seemingly no way to examine what sample rates or bit depths the device supports, seemingly no way to subscribe to any kind of notification when the device has actually changed sample rate (or other properties) or when playback has stopped etc, no ability to lock the device to prevent other processes changing the sample rate or other properties, no ability to get device time or determine if the device is synchronised with system time.

Some of these missing things can be added fairly easily to the existing API of course, but I don't know enough about plan9 to suggest how, for example, notifications for device property changes could be added.

As it stands this interface is almost useless even for casual home users who just want to play back audio: multiple channel support is a basic requirement these days. Serious audio work is not even possible at all.

5 comments

That calls for an obscure ioctl with an impossible name. Simply use SNDGTDVCLTNC to query the device's latency. Like the actual TIOCSLCKTRMIOS which can be used to lock the termios: http://www.kernel.org/doc/man-pages/online/pages/man4/tty_io...
Were the sound APIs from other operating systems of that era any less limited? Presumably you could reproduce a modern API just as easily with a filesystem, using the same general schema.
> that's a terribly limited API.

Plan 9's users consider that a feature. Standing boast: "GNU's compiler manual is bigger than our whole system!"

> I don't know enough about plan9 to suggest how, for example, notifications for device property changes could be added.

You'd add a virtual file named "ctl". Processes could open it and call read, which would block until something changed, then return with the notification.

Those processes will need threads that work. Plan 9's do.

The thing to keep in mind is that this was written for a SoundBlaster back in the early 90s. I remember being really impressed that Commander Keen 4 could use the SoundBlaster 16 in my 486 to make decent music at all.

As for notifications of device property changes, you would probably get them by reading from the various control and status files. Although I use Plan 9 at home and at work, I have never really done anything with audio, I'm afraid.

> As it stands this interface is almost useless even for casual home users who just want to play back audio: multiple channel support is a basic requirement these days.

Really? I must therefore, be somehow a less than casual music listener - I am perfectly happy with my stereo.

I wasn't suggesting that all users require it, merely that a non-trivial number do; more for watching video with multichannel soundtracks than listening to music.