[MPlayer-dev-eng] [PATCH] Adding Radio support to MPlayer (update)

[Vladimir Voroshilov]

Jindrich Makovicka wrote: 
> Can't you just do all this stuff in grab_audio_frame?
Here is my comment to thread procedure:
+ * Module MUST read  sample_rate*samplesize*channels bytes every second. To tell
+ * the truth it must read sample_rate*samplesize*channels/period_time every
+ * period_time microseconds. If it should try to read data faster, it will be
+ * in block state wating another part of audio data. If it should do it
+ * slower then xrun event will occure and buffer will be lost.
+ *
+ * No guaranties that fill_buffer_s will be called in such exact interval.
+ * Usually it calls when demuxer's buffer becomes empty. In that case demuxer
+ * continiously calls fill_buffer_s until buffer fills (sound is not playing
+ * during this call). Thus i must gurantie that audio data will be already available
+ * for next fill_buffer_s call to make pauses as short as possible.

Before sending patch i also tryes to remove thread from code. I have moved 
ringbuffer-filling staff from audio_grabber into grab_audio_frame.
After that listening sound using capture staff became impossible.
1. fill_bufer_s is called many times to fill demuxer's internal buffer
(about 100kb in my case) that causes wait data events inmy code
2. after buffer fills, MPlayer plays received data very fast (about double of quadro-speed)
3. next step 1 again.

In other words: i must call audio_in_get_chunk in  the  equal time intervals, but i
cannot guarantie that audio grab_audio_frame will be called in similar time intervals.
thus, thread is using to make audio data reading in a constant speed (or similar).

> 
> -- 
> Jindrich Makovicka
> _______________________________________________
> MPlayer-dev-eng mailing list
> MPlayer-dev-eng at mplayerhq.hu
> http://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng

-- 
Vladimir Voroshilov mailto:voroshli at univer.omsk.su
Omsk State University
JID: voroshil at jabber.ru
ICQ: 95587719