Rockbox mail archiveSubject: Re: FS#11232: software mixer
Re: FS#11232: software mixer
From: Thomas Martitz <thomas.martitz_at_student.htw-berlin.de>
Date: Sun, 02 May 2010 21:22:37 +0200
Am 02.05.2010 20:11, schrieb Jeff Goode:
> On 5/2/2010 14:03, Jeff Goode wrote:
>> On 5/2/2010 04:44, Jens Arnold wrote:
>>> On 01.05.2010, Jeff Goode wrote:
>>>> I'd like to know if there's some way to force SDL to behave
>>>> like a target, with a very small FIFO buffer rather than
>>>> its own large playback buffer, or at least not always
>>>> insist on its being full. Ideas?
>>> Perhaps just make the mix buffer larger for the sim?
>>> I have no real idea how to get around this while keeping SDL
>>> (and hence portability).
>> I think you're right about this and I'm going to give that a try
>> next. The sim audio driver still won't "DMA" like a target but at
>> least it ought to fill the buffer as SDL expects. Latency will
>> skyrocket though. Instead of 23 ms tops it'll be more like 250 ms.
>> I guess this isn't a problem as long as we're just using the sim to
>> test code, but it might if we're going to use it as a basis for
>> Rockbox-as-app. In that instance, the Rockbox mixer code would have
>> to be thrown out in favor of SDL mixer or some other library function.
> I just thought of another implication. If the Rockbox mixer has to be
> disabled later for the sim or Rockbox-as-app in favor of a library
> function, that would imply that some of the mixer code (such as the
> mixer ISR callback) doesn't belong in pcmbuf, but lower down toward
> the driver level, perhaps in pcm.c. Code in pcmbuf really ought not
> be target specific. Actually, neither should pcm.c but it's closer to
> the hardware level. I'm a bit conflicted here. Either way it's
> bloody mess.
Don't think about the future too much. You could invent some #defines,
but just don't worry about RaaA too much :)
Received on 2010-05-02