Re: [Jack-Devel] jack 1.9.8 + many many connections = problems?

> 
> On 01/02/2012 01:19 PM, Stéphane Letz wrote:
>> 
>> Le 2 janv. 2012 à 20:41, Fernando Lopez-Lezcano a écrit :
>> 
>>> On 12/31/2011 12:16 PM, Stéphane Letz wrote:
>>>> If  JackAlsaDriver::WriteOutputAux (in JackAlsaDriver.cpp file) works correctly, then you'll have to trace what happens in "JackGraphManager::GetBuffer(jack_port_id_t port_index, jack_nframes_t buffer_size)" (line 168 in JackGraphManager.cpp), possibly checking what code path is used : // This happens when a port has just been unregistered and is still used by the RT code OR // No connections : return a zero-filled buffer, OR // One connection OR // Multiple connections : mix all buffers
>>> 
>>> First test results (of many to come)
>>> 
>>> I added code to record changes in "len"  inside JackGraphManager::GetBuffer and print them as errors so I can see them in the log.
>>> 
>>> Regretfully I don't see any strange behavior when ports go into "silent mode". The number of connections reflects what it should be, and it never goes to zero after the initial connection process finishes.
>> 
>> 
>> Then in JackAlsaDriver::WriteOutputAux you should check that the buffer coming from Jack core
>> 
>> (jack_default_audio_sample_t* monbuf = (jack_default_audio_sample_t*)fGraphManager->GetBuffer(fMonitorPortList[chn], orig_nframes); )
>> 
>> actually contains something.... and if yes, then you'll have to trace what happens with this buffer in the ALSA backend itself...
>> 
>> Stéphane

Le 2 janv. 2012 à 23:48, Fernando Lopez-Lezcano a écrit :

> Found it!
> And of course it was not jack's fault...
> 
> I started factoring the connections out in the code (major code changes) to try to isolate the problem. I found that it was not being caused by the connections at all. Most probably the clues I got were wrong, maybe due to wrong ordering of the output due to buffering being different in all programs used. I finally traced the problem to a few un-initialized variables in a supercollider ugen (LR4 high pass and low pass filters used in the speaker crossover). Those were the cause of the big noises in the output stream. I still can't think how this could result in an audio port that stops working! Must be something inside alsa itself? Still puzzling. Still a lot more testing to do but it looks fine for now...
> 
> Many many thanks for your patience and all the debugging hints!
> 
> As I feared I was doing something wrong...
> -- Fernando
> 

So happy to know this is not JACK fault....

Stéphane 

1325577733.26392_0.ltw:2,a <EE518170-58A3-4120-BFB4-5CF4C2FCFA94 at grame dot fr>