Re: [Jack-Devel] R: A couple of related issues in jackd on ARM

OK.

I would recommend trying latest git (1.9.10). Some work was done between 1.9.8 and current version in this area (event if I think the solution is still not so good...)

Can you try and report?

Thanks.

Stéphane 


Le 9 janv. 2013 à 09:31, MONTANARO Luciano (MM) a écrit :

>> -----Messaggio originale-----
>> Da: Stéphane Letz [mailto:[hidden]]
>> Inviato: martedì 8 gennaio 2013 20:45
>> A: MONTANARO Luciano (MM)
>> Cc: [hidden]
>> Oggetto: Re: [Jack-Devel] A couple of related issues in jackd on ARM
>> 
>> 
>> Le 8 janv. 2013 à 20:13, MONTANARO Luciano (MM) a écrit :
>> 
>>> Hi all again,
>>> I am having new problems with jackd2, after our embedded platform
>> switched to the 3.1 kernel.
>>> Actually, I think they were present with our previous kernel as well, but
>> they have become systematic while once they were sporadic.
>>> 
>>> I think I have found the problematic code, but I need some insight from
>> someone that knows the code.
>>> The first problem I am seeing is a very high number of xrun notifications,
>> tens of them a second.
>>> They is due to alsa_driver_wait() returning with 0 as its frame number,
>> which normally means an xrun has occurred, but in this case what seems to
>> be happening is that jack_wait returns "normally", but with a capture_avail of
>> 0 and a playback_avail of 512 on 9 calls out of 10. The tenth call I get both
>> capture_avail and playback_avail set to 512. The wait_status is set to 0, as in
>> "everything normal", I guess, and so I tried to modify JackAlsaDriver to skip
>> the notification in this case, and things seem to be working fine, no
>> noticeable glitches in the audio playback at all.
>> 
>> Cannot answer here: what ALSA gurus think of the possible fix?
>> 
>>> 
>>> The second problem I was referring to is that this high number of
>> notifications is triggering a problem in the JackRequest code:
>>> The CheckRes() macro checks for errors from the Read/Write calls, but
>> these calls may silently fail: they can return without writing or reading, and
>> this is accounted as success, but then Read() may return uninitialized data or
>> Write is not retried when it should.
>>> 
>>> There is code like this:
>>> 
>>>        CheckRes(JackRequest::Write(trans));
>>>        CheckRes(trans->Write(&fName, sizeof(fName)));
>>>        CheckRes(trans->Write(&fProtocol, sizeof(int)));
>>>        CheckRes(trans->Write(&fOptions, sizeof(int)));
>>>        CheckRes(trans->Write(&fUUID, sizeof(int)));
>>> 
>>> Where I think after each Write there is potential for a needed retry, which
>> is not done at all. Am I missing something?
>> 
>> CheckRes was supposed to fail in case of error?
>> 
> 
> Yes, but the JackClientSocket::Read/Write functions return 0 if len != returned length.
> So CheckRes is fine with them.
> 
>> Any log of the problem to show?
>> 
> 
> A log showing the problem is attached.
> The interesting lines are near the end, but maybe you can spot something else that is useful.
> 
> The cause of the abort is that Jack seem to receive ConnectPorts with a -1 port id, but as you can see, at line 10311, there is an
> "Unknown Request -1", and a similar one at line 10125.
> 
> Thank you,
> Luciano
> 
>> Stéphane
> 
> Confidential Notice: This message - including its attachments - may contain proprietary, confidential and/or legally protected information and is intended solely for the use of the designated addressee(s) above. If you are not the intended recipient be aware that any downloading, copying, disclosure, distribution or use of the contents of the above information is strictly prohibited.
> If you have received this communication by mistake, please forward the message back to the sender at the email address above, delete the message from all mailboxes and any other electronic storage medium and destroy all copies.
> Disclaimer Notice: Internet communications cannot be guaranteed to be safe or error-free. Therefore we do not assure that this message is complete or accurate and we do not accept liability for any errors or omissions in the contents of this message.
> <jack_aborting.log>

1357725349.14598_0.ltw:2,a <9E75F57E-C258-4463-B86F-E9234705C848 at grame dot fr>