[Clam-devel] Clam in the long run

[Pau Arumi]

En/na Moritz FISER ha escrit:
>> En/na Moritz FISER ha escrit:
>>> Dear Clam Developers,
>>>
>>> I'm currently working on my first app. using the Clam Network. It is 
>>> supposed to set up a Network at the start and then run for a looong 
>>> time.
>>
>> Hi Moritz, and welcome to develop with clam.
>>
>> First note that I've manually accepted this mail as a list admin
>> since you where not subscribed. So please do it.
> 
> Hi Pau, thanks for your reply, I noticed I subcribed with another alias 
> to my mail address, should be sorted now.
> 
>>> So far it is working quite well, but after an uptime of a day it's 
>>> running into troubles. Since I implemented the processings and 
>>> networkplayer myself I'm not sure if I perhaps made a mistake 
>>> concerning the usage of ports there.
>>
>> Did you implemented a new networkplayer? For a new audio backend
>> maybe? A patch would be helpful (both player and processings).
> 
> The player is a modified version of the PANetworkPlayer, but with an 
> additional buffer and multithreading, to avoid dropouts at all costs and 
> being able to save unprocessed data in case of a crash. It's pretty 
> specific to my problem and just implemented to record for now.
> 
>>> Anyway, I've analyzed the problem (which takes a while as you can 
>>> imagine :P) and  tracked it down to the Consume() method in 
>>> ReadingRegion.hxx, where mPos gets assigned Pos()+Hop(), which leads 
>>> to an overflow of mPos in the long term of course, since it's called 
>>> by the Do() of my processings every time.
>>> Before looking too far into it, I decided to ask here for some 
>>> further help, since it could just be a usage error on my side. Hope I 
>>> could make my problem clear,
>>
>> It's difficult to judge with so few elements. I suggest some
>> actions:
>> - run (with a small input) with valgrind to detect mem errors or
>> leaks.
>> - try to reproduce it only with clam processings and network
>> player (instead of yours).
>> - send a patch so we can reproduce it here.
> 
> Ok, I checked the problem again and it seems my suspicion about it's 
> origin got confirmed. Here's what it's about:
> 
> I'm instantiating a Clam Network, add my processings and connect them by 
> ports. After starting the Player, the Do() methods get called, and in a 
> processing's Do() it calls a Consume() on it's port. So far everything 
> works fine until 13.52 hours have elapsed, which corresponds to an 
> overflow of a 4byte int at a samplerate of 44100 Hz. The according 
> integer can be found in Region.hxx - long  mPos (4 bytes on my machine).
> 
> After successive calls of Consume(), mPos produces an overflow and 
> causes problems.

That's right we have an ever increasing integer for the sample
position! We thought that a long int would be enough for all uses.
And you proved that wrong.

> My immediate fix of course was to change the datatype from long to long 
> long, which should work fine for me for the next 6.7 Mio. years at 44100 
> Hz.

It's a relieve to learn that you don't plan to run your network for
longer than that :)
Please send the patch and I'll commit it.

Pau