On Tue, Feb 21, 2012 at 10:18:24PM +1300, richardtoo...@paradise.net.nz wrote: > Hi, guys. > > I've got a little issue with this Spectrum emulator and audio, and I've hit a > brick wall with what to do next. > > This might be a question of "oh, just do this in audioctl" - I just > don't know, and I'm not managing to find the answer myself. > > The emulator runs fine, but sound isn't quite right. This message appears in > the terminal window: > > Major slip in writing sound device > > (This is on a couple of i386 machines.) > > spsound.c has that message, it looks like the code keeps track of > the number of sample bytes written, then asks the audio (ioctl > AUDIO_GETINFO) how many bytes it has written. >
Hi, Note that AUDIO_GETINFO returns samples, not bytes. Furthermore it may not be enough in all cases. Depending on what the software needs, the PERROR ioctl might be necessary to take into account underruns as well. > After a few iterations of this, the audio playback has fallen behind, and the > program decides to ignore its idea of where it has gotten to, and go with the > samples value from the ioctl call. > > I've added some debugging, and I don't understand how this occurs: > > samplenum 624 written 936 auinfo.play.samples 416 (seek is 832), diff is 520 > > samplenum is the number of bytes the emulator has just written to /dev/audio. > The code writes 312 bytes, then another 624 - that gives the 936. > > It uses the ioctl and gets told we've played 416 samples, and that > there are 832 pending. How can that be? If we've requested 936, > how can audio think that there are 416+832=1248 sample bytes? > haven't looked at the code, but audio buffer may have underrun. > There are audio errors happening (see audioctl output below) so I > can see that obviously things aren't generally happy, but I'd love > to understand why the ioctl says there are more bytes going through > than were requested. > > And anything else to try, cluesticks, etc. I guess moving the sound > to SDL or libsndio are options, but I'd like to understand what is > happening here before I move on. > the main reason for introducing sndio is to avoid such complications and to keep such programs simple/deterministic. Furthermore, the audio(4) api is not used by ports anymore and might change sooner. -- Alexandre
