[Clam-devel] Clam in the long run

[Moritz FISER]

> 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.

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.

I just wasn't sure if there is a designated method to avoid this  
overflow or if it just wasn't intended to run for a longer time.

> Don't hesitate to expand on what is your project about. There are
> maybe things that could be integrated to clam?

Maybe there will be some components general enough to submit to Clam,  
but I'll have to work through them again.

Moritz