[Clam-devel] Re: Network finish reading bug + Pause
gglobot at gmail.com
Sat Oct 20 08:04:48 PDT 2007
>En/na globot ha escrit:
>>i have something strange on network players...
>>i call a network with the Start() function, evrything is fine, but
>>when the file end i got a 100% cpu usage and i can't Stop() the
>>network. The result is that my prog freez waiting for the end of the
>>On NetworkEditor it look like the same, i play a file and in the end,
>>100% cpu usage, and if i click stop or play button evrything freeze
>>But if i call MultiChannelAudioFileReader::Stop() after the end of the
>>file, the CPU usage fall to 0%
>>so i think there is a something wild in AudioFileIO or Reader Class ...
>>secondo, When the file reader has finish reading a file, the last
>>value of Current Time is not the Duration of the file as it should be
>>in my opinion.
>>And the file reader + network doesn't seemed to stop.
>>I made a small patch to stop the file player when reach EOF
>>(apparently returning FALSE is not enought)
>Yes this seems a bug of MultiChannelAudioFileReader.
>The expected behavior after EOF should be outputing silence without any
>disc access nor computation. But not stopping the processing as your
>Have you tried with MonoAudioFileReder, I think it doesn't show that bug.
>And have you tried to spot the cause of the bug? It seems a good time to
I was thinking that this bug was du to a repeated call of the
MultiChannelFileReader->Do() without delay
now i made an other patch not returning directly if EOF reached, but
filling buffers with 0 instead of reading from disk
I think the Pause function should have the same behaviour so i did...
For now i just implement the Pause as public methode of XXXFileReader
>About the CurrentTime bug I have no time to go into it right now. I
>think Roman implemented it maybe he is around.
>I'd be very happy if somebody can do a minimal example that reproduce
>this bug so I can incorporate it as an automatic functional test.
I was thinking this bug is due to the fact that the Do function return
directly if EOF reached, it mean that the last CurrentTime is the
beginning time of the last buffer, and not the end of file. It should be
incremented one more time after EOF.
But I found that the very end of the file doesn't seem to be played but
i have no time to search why ... (here there was possibly to problems
and the first one should be solved by the patch)
>BTW now that we are on this subject, there is an obvius refactoring to
>be made here: unify Mono and MultiChannelAudioFileReader classes. By
>default it should create as many ports as channels have the audiofile
>(passed in the configuration).
>But it should also might be configured with a fixed number of outports,
>and try to do a sensible mapping (outputting only a subset of channels
>or repeating channels, depending on the situation).
>This fixed number of ports feature is useful when using a network
>outside the network editor as the user can not redo ports connections
>after choosing a file.
actualy, My application redo connection from file reader, cause i am not
sure if there is 2 channels on the files i read :
- I get the pointer on the file reader
- check the number of channel
- reconnect ports (several time if there is not enought channel)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
More information about the clam-devel