[Clam-devel] Clam in the long run
parumi at iua.upf.edu
Tue Sep 4 03:44:16 PDT 2007
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
>> 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
>> - run (with a small input) with valgrind to detect mem errors or
>> - 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
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.
More information about the clam-devel