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

[Pau Arumi]

This last patch has been commited (rev 10875). Thanks!

Please do a backup of the *AudioFileReader.*xx files before updating 
because it will cause conflicts as I've modified the coding style of 
some lines. (I could not commit your patch as-is in the first place 
because I couldn't apply the patch automatically but by hand)

There is a clear smell in the multichannel reader: two almost identical 
Do methods, one without arguments (uses ports) and the other gets a 
vector of Audios. This duplication should be removed.
 (1) If nobody uses the second interface Do(vector<Audio>) it could be 
removed
 (2) Do() could delegate to the previous Do
I'd rather do (1) but testfarm is off right now. But maybe anyone have a 
reason for keeping Do(vector<Audio>)?

And then, as said in another mail, there is the pending refactoring of 
merging Mono and MultiChannel versions.

Pau



En/na globot ha escrit:
>
>> 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
>>
>>
>>  
>>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Clam-devel mailing list
> Clam-devel at llistes.projectes.lafarga.org
> https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel