qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: [RFC][PATCH 4/4] Add support for Marvell 88w8618 / Musi


From: Jan Kiszka
Subject: [Qemu-devel] Re: [RFC][PATCH 4/4] Add support for Marvell 88w8618 / MusicPal
Date: Thu, 17 Apr 2008 21:06:57 +0200
User-agent: Thunderbird 2.0.0.12 (X11/20080226)

malc wrote:
> On Tue, 15 Apr 2008, Jan Kiszka wrote:
> 
>> malc wrote:
>>> So just leave the callback until free get's big enough, you will get
>>> dropouts either way, it's just that. I guess you might also use the
>>> AUD_init_time_stamp_out/AUD_get_elapsed_usec_out mechanism
>>> (implemenation
>>> is right at the end of audio/audio_template.h), but i still think that
>>> just going with free is saner approach.
>>
>> Well, took some iterations to switch my mind completely to the new
>> model, but now this timestamp-free version runs as smooth as the
>> previous one:
> 
> Glad to hear that.
> 
>> static void audio_callback(void *opaque, int free)
>> {
>>     mv88w8618_audio_state *s = opaque;
>>     unsigned int block_size, written;
>>
>>     block_size = s->threshold/2 - s->block_written;
>>     if (free - s->last_free < block_size)
>>         return;
>>
>>     audio_fill_mixer_buffer(s, block_size);
>>     written = AUD_write(s->voice, s->mixer_buffer, block_size);
>>
>>     s->last_free = free - written;
>>
>>     if (written < block_size) {
>>         s->block_written += written;
>>         return;
>>     }
>>     s->block_written = 0;
>>
>>     if (s->play_pos == 0) {
>>         s->status |= MP_AUDIO_TX_HALF;
>>         s->play_pos = s->threshold/2;
>>     } else {
>>         s->status |= MP_AUDIO_TX_FULL;
>>         s->play_pos = 0;
>>     }
>>
>>     if (s->status & s->irq_enable)
>>         qemu_irq_raise(s->irq);
>> }
>>
>> [ This would be even simpler if I could assume written == block_size ||
>>  written == 0. But who knows... ]
> 
> The API has no way to enforce this, therefore the only sane option is to
> assume it will happen. I confess i don't quite get the logic behind the
> last_free, but as you said, it works smoothly, so be it.

It's kind of a beautification: If the host buffer is larger than
s->threshold (the buffer size the guest wishes to use), there would be
an initial IRQ burst otherwise until the host buffer is consumed.

Jan

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]