[Clam-devel] Re: Network finish reading bug + Pause

[globot]

>En/na globot ha escrit:
>  
>
>>Hi (again)
>>
>>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 
>>Network
>>
>>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 
>patch does.
>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 
>fix it.
>
>  
>
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)

>Cheers,
>Pau
>
>
>  
>

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: FileReaderEOF_CrashFix_2.patch
URL: <http://lists.clam-project.org/pipermail/clam-devel-clam-project.org/attachments/20071020/5cc7db23/attachment.ksh>