SOC2006::ryanb

Long time, no updates. I’m terribly sorry about that.

ioctl status

Rudimentary support for a bunch of audio ioctls has been added, and a handful are currently on hold while 4Front hammers out some more details. Unfortunately, some of the cooler aspects of this project, specifically the mixer extensions, are also on hold as the specifications appear to be in flux. However, as they are currently shipping an unofficial readme & sample programs using said extensions, I’m going to go ahead & start prototyping interfaces using the emu10kx and ich drivers as baselines.

Some controls are up in the air due to differences in design. For an example, go to the ioctl reference page & take a peek at SNDCTL_DSP_COOKEDMODE. ... I was about to write about inaccuracy about information returned by SNDCTL_SYSINFO and SNDCTL_AUDIOINFO, but after rereading and rethinking a few things, I just came up with some different ideas, so I’ll try those out & write again soon.

Finished cataloging what appears to be the bulk of useful ioctls supported by the OSS v4 API. Notable exceptions are the MIDI and mixer extensions. For now, MIDI is at a lower priority, and the mixer extension specifications seem to be in flux. (I’ll need to ask 4Front about that.) Check out the results here.

Based on that list and input from Alexander, I’ll attack ioctls in roughly this order:

Muy importante:

• SNDCTL_{SYS,AUDIO}INFO
• 
  
• SNDCTL_DSP_{GET,SET}_{PLAYTGT,RECSRC}_NAMES
• 
  
• SNDCTL_DSP_{GET,SET}{REC,PLAY}VOL
• 
  

Next up, in random order:

• SNDCTL_DSP_COOKEDMODE
• 
  
• SNDCTL_DSP_CURRENT_[IO]PTR
• 
  
• SNDCTL_DSP_GET[IO]PEAKS
• 
  
• SNDCTL_DSP_HALT_{IN,OUT}PUT
• 
  
• SNDCTL_DSP_LOW_WATER
• 
  
• SNDCTL_DSP_SILENCE, SNDCTL_DSP_SKIP
• 
  

Thoughts?

Quick update:  A bit behind at the moment.  Catalogued all of the existing ioctls in pcm/{dsp,mixer}.c and midi/sequencer.c to get a sort of “big picture” grasp of current code.  Next, need to go over everything at OSS and start writeups on all the new stuff.

Further down the road, after the API is in place at least in name, I’ll need to start testing/tweaking soundcard drivers.  I have access to an ICH and an EMU10K1, so I can test/tweak with those, but will probably need to defer on all others.  I’ve been using Yuriy Tsibizov’s emu10kx driver for some time now, and am pleased to read that it’s coming to the base system.  I’m wondering if it’ll sit next to the existing emu10k1 driver or just replace it completely.