On Thu, 4 Oct 2001, Christoph Reichenbach wrote:
> If I understand you API correctly, the OPL emu layer (or whichever other
> emulation layer might end up being written) will be using the callback
> function, which will provide this information anyway.
Correct.
> The sound formats of other resources are fixed, so from this point of view
> there's no need to be able to retreive this information, except for
> debugging purposes.
Yes.
> The only case where this could be releavant would be for 'incompatible'
> samples, i.e. samples with the LCM of their sample rates being above what
> the hardware offers (or the LCM of their sample rate and the
> preconfiguresd sample rate S set being > S). In these cases, it would be
> possible to transform them and cache the results.
> But I don't think that we'll encounter this problem in SCI unless we allow
> external samples, and those could be restricted to fit our needs.
We'll use the samplerate/format converson from ALSA source... then mix it
with the callback buffer on the fly.
> > pcm_sample_play(handle, *databuffer, *pcm_sample_format_s) return shandle
I should probably have written something like *static_databuffer.
> The question of 'who takes responsibility for the buffer' should be
> answered in the API docs here. My suggestion would be that either the
> caller takes this responsibility, since we'll probably be using statical
> buffers for OPL emu output, or that this can be chosen freely.
> In the former case, the caller must be able to determine when a sound has
> finished playing, so that it may release the resource lock for the
> resource containing the sample. While this could be done with the
> pcm_sample_getpos() call returning -1 (or whatever), this would require
> continual polling to get this point. OTOH, this is also the 'safest' way
> to do this, since it can be done in synchronity with the main
> process/thread.
We could also make a funtion pcm_sample_play_onlyreturnwhenproperlydone
> > pcm_callback_buffersetup(handle, *make_buffer_function(*pcm_dev_format))
>
> The callback also needs a buffer to write to.
Oops forgot:
pcm_callback_buffersetup(handle, *make_buffer_function(*pcm_dev_format,
*buffer))
> > pcm_callback_stop(handle)
>
> Implies that there is only one callback function; if we needed more than
> that, we'd have to do multiplexing on a lower level. But I don't see how
> we could need more than one of these, so this looks appropriate.
We could simply extend things with a callback_handle if things go bad.
> > pcm_volume...?
>
> Should be handled at the mixer level, i.e. should be present here- some
> sound hardware does not provide a hardware mixer, so we must not rely on
> the sound driver to provide this functionality.
pcm_volume_set(volume)
pcm_volume_get() return volume
> (You could check for this at run-time, of course, using the hw mixer
> where available and falling back to emulation where not, similar to what
> the gfx layer does with mouse pointers and stippled lines).
agree.
> Well, I like it; as far as I can tell, this handles our requirements quite
> adequately. There is one problem I see as far as driver development is
> concerned, though, and that problem is the callback funcion.
> On systems where we have direct hardware control, it'll be easy to invoke
> this from an IRQ handler. Unfortunately, we don't support any of these
> systems at this time. Do sound APIs provide this mechanism in general?
They should or they are not made for game programmers. (==fucked up)
> It'd certainly be helpful... From what I gathered, ALSA supports
> poll()ing on the pcm handles, which would allow us to do this from a
> clone()d thread (it's A_L_SA, after all...) if ALSA does not do this
> natively. But I don't know about OSS or the sound APIs provided by other
> OSses...
It's also the way to program a sound board natively... :-)
I just hope the opl emulators are fitted to plug in to this scheme. If
they are not it would make sense to do a rewrite of the emu.
--
/Rickard Lind
