Proposal of new feature to wavparse

[Tiago Katcipis]

On Fri, Oct 31, 2014 at 11:44 AM, Tiago Katcipis <katcipis at inf.ufsc.br>
wrote:

> Sebastian,
>
> I don't know why I did not receive your answer on my email, luckily I
> checked the mailing list archive and was able to see it there (it is not
> the first time this happens :-().
>
> When ignore-length is used, wavparse should probably not keep track of
>> how much data is left itself but continue reading until upstream returns
>> EOS. That should solve your problem, right?
>
>
> It should, but it doesn't :-). My problem is the dataleft control. It
> actually checks how much data has already been streamed and if it comes to
> 0 it will send an EOS, even if the upstream still have more data.
>
> This can be seen here:
>
>
> http://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/gst/wavparse/gstwavparse.c#n1941
>
> I thought the ignore-length would do the job too, I was surprised when I
> was still getting EOS.
>
>
> Apart from that, what you're describing here is never going to work
>> reliable in the general situation. It can happen because of various reasons
>> that wavparse reads faster than the writer writes, and the you will get an
>> EOS too early. But you probably know that already :)
>
>
> Yeah I know, but the old solution using gstreamer 0.10 has been made this
> way and we did manage to make it reliable enough for usage :-) (it is
> alread deployed on several clients for some time).
>
> I did some several tests this week and we keep a reading speed that does
> not exceed the writing (more than two hours for example, which is enough
> for a lot of skews).
>
> It is not a very normal usage I know, but so far it has been quite useful
> for me at work.
>

Just to make it more clear, both the write and the read are synchronized on
the clock (at 8000 samples per second). Of course two machines will not
have the exact same clock, but it is good enough to make the solution works
(but only when I removed the dataleft logic from wavparse). I tested for a
possible skew between the writer and the reader and even after 2 hours of
usage the delay between time of write (me speaking on the phone) and time
of read was pretty much the same (not perceivable by a human :-).

The system does not require a perfect live situation, so this rudimentary
solution works well. I seek to a position near the current end of the file
and start the reading.



>
>
> On Sat, Oct 25, 2014 at 9:45 PM, Tiago Katcipis <katcipis at inf.ufsc.br>
> wrote:
>
>> Hi,
>>
>> First I will describe my problem:
>>
>> I have an IMA ADPCM WAV file being recorded, as the file is recorded I
>> need to:
>>
>> 1 - Open it, get the duration from the wav header and seek to near the
>> end (the client wants to hear what is being said on the audio with the
>> minimum latency possible).
>>
>> 2 - Start to stream the audio to a client while it is still being
>> recorded (with care to not send it faster then it is being recorded).
>>
>> 3 - Just stop to send the audio when the file stops being recorded
>> (basically I hit EOF).
>>
>> I was able to use wavparse ignore-length property to bypass the duration
>> found on the header file. But still I was getting EOS while the recording
>> was still going on.
>>
>> Checking out wavparse closer it uses a field dataleft to define when to
>> EOS. Disabling EOS from dataleft I was able to do everything I wanted
>> (seek, get duration and stream audio until the source indicates that there
>> is no more data left).
>>
>> It worked perfectly fine, but I did some nasty stuff on the wavparse and
>> basically forked it as another plugin. I can think on a way to make this
>> work using wavparse, through a property (like ignore-length), but I don't
>> know if the use case is good enough to justify the addition of this feature.
>>
>> Adding this kind of feature on wavparse makes sense ?
>>
>> Best regards,
>> Tiago Katcipis
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20141031/ea2e0786/attachment-0001.html>