Ticket #348 (closed bug: fixed)

Opened 9 years ago

Last modified 8 years ago

amdtp streamer crashes when changing buffersize

Reported by: adi Assigned to:
Priority: minor Milestone:
Component: generic/streaming Version: FFADO SVN (trunk)
Keywords: Cc:
The device the bug applies to:

Description

With the recent buffersize changes, it is possible to crash ffado when increasing the buffer size to something bigger than the initial value, resulting in the following failed assertion:

jackd: src/libstreaming/amdtp/AmdtpReceiveStreamProcessor.cpp:396: void Streaming::AmdtpReceiveStreamProcessor::decodeAudioPortsFloat(quadlet_t*, unsigned int, unsigned int): Assertion `nevents + offset <= p.buffer_size' failed.

I might have some time later next week to have a look, just wanted to document the problem so it won't be lost.

Change History

03/18/12 16:17:11 changed by jwoithe

For what it's worth, I *think* this would be an issue within the specific driver (AMDTP) rather than the generic layers because I've successfully tested an increased buffer size with other devices. YMMV.

03/18/12 16:38:51 changed by jwoithe

I just had a quick look at the code (which is all I can do right now). The resizing of the port buffers is handled in the generic layer, so it's hard to see how m_buffersize can avoid being updated with the larger size. One thing that's worth noting is that the port will only resize its buffer if it's in the E_Created state or has been disabled (see src/libstreaming/generic/Port.cpp line 91ff, Port::setBufferSize()). On shutdown it's clearly not possible for the port to return to the E_Created state, so for buffer resize we rely on the ports being disabled. If the flow of the AMDTP driver is such that this doesn't occur before the buffer resize is requested then this would fail. However, it fails with a "Fatal" debug notification which IMHO isn't masked by the verbose level, so if you're not seeing any "Port (...) not in E_Created/disabled state" messages then this can't be the issue.

So maybe there is a lurking problem in the generic layers which is either not triggered with the devices I have or is for some reason intermittant for my devices.

04/02/12 07:23:08 changed by adi

  • status changed from new to closed.
  • resolution set to fixed.

Fixed in r2112.