[FFADO-user] Focusrite Saffire PRO 26/ PRO 40, two transmitters/ two receivers (was Re: Focusrite Saffire Pro26)

[Stefan R. <st...@s5...>]

On Feb 06 Takashi Sakamoto wrote:
> On Jan 31 2016 20:17, Stefan Richter wrote:
> >   - Last time I checked, snd-dice supported only a subset of audio
> >     channels of Focusrite Saffire PRO 40.  Jonathan pointed out to me that
> >     this is a device with two "endpoints".  In the list archive link
> >     above, Hector wrote in his patch changelog about Saffire PRO 26 that
> >     it has got "two transmitters, like the 40".  I suspect that this means
> >     that snd-dice would presently not expose all of the PRO 26's channels
> >     either.  
> 
> Could I ask you more explaination about the 'endpoints'?

First off, I know little about FireWire audio protocols in general, and
virtually nothing about DICE related protocols.  At this point, I can
report some observations but can't give explanations.

I have got a Saffire PRO 40; the "older" model with the original chipset
and with firmware which ffado-mixer still supports.  I noticed two things:

 1) FFADO's streaming driver exposes
	20 PCM capture channels  (0...9  and 11...20),
	20 PCM playback channels (0...11 and 13...20),
	1 MIDI capture channel   (10),
	1 MIDI playback channel  (12)
    to Jackd.  snd-dice on the other hand, tested right now with kernel
    v4.2-rc5, with "seq" MIDI driver selected in qjackctl, exposes
	10 PCM capture channels  (1...10),
	12 PCM playback channels (1...12),
	1 MIDI capture channel,
	1 MIDI playback channel
    to Jackd.  (If I select "none" or "raw" MIDI driver in qjackctl, I get
    the same number of PCM channels but no MIDI channels.)  I attached the
    outputs of "jack_lsp -A" from sessions with FFADO and with snd-dice.

 2) Last year I helped debug a hardware quirk in the JMicron JMB38x
    OHCIs.  The quirk resulted in the OHCI being often detected as having
    4 IR DMAs and 0 IT DMAs, even though it in fact implements 4 IR and 4
    IT DMAs, which is also the minimum required by the OHCI
    specification.  When firewire-ohci came up with 4/0 DMAs, and jack was
    started with FFADO, FFADO would report the failure to initialize the
    IT context for normal audio devices --- but with Saffire PRO 40 it
    would report failure to initialize _two_ IT contexts.  I reported this
    surprising behavior at ffado-user, and Jonathan responded thus:

	Subject: Re: JMicron JMB38x train wreck (was Re: [FFADO-user] FFADO and KxStudio 14.04)

	On May 14 Jonathan Woithe wrote:
	> On Thu, May 14, 2015 at 02:17:09PM +0200, Stefan Richter wrote:
	> > > 01619600215: Fatal (IsoHandlerManager.cpp)[1852] enable: Could not do xmit initialisation (16: Device or resource busy)
	> > > 01619601709: Fatal (IsoHandlerManager.cpp)[1852] enable: Could not do xmit initialisation (16: Device or resource busy)  
	> > -v6 log: jack-saffire_pro40-jmb381.log (152 kB)
	> >          http://pastebin.com/eAAmSz4M
	> >          http://pastebin.com/raw.php?i=eAAmSz4M (plain text)
	> > 
	> > Why is FFADO starting two IT contexts on the PRO 40?  
	> 
	> Good question.  I have no idea.
	> 
	> Looking at the log we see this:
	> 
	>   registerStream:  4 streams, 4 handlers registered
	> 
	> So FFADO thinks there is a need for two tx streams and two rx streams. 
	> This is seen clearly under the "ffado_streaming_start" line where 4 streams
	> are reported.  Interestingly enough it seems the Pro40 connected to device
	> node /dev/fw3.  Normally this would be /dev/fw1 with nothing else on the
	> bus.  What happened to /dev/fw1 and /dev/fw2?
	> 
	> Anyway, looking at the "showDeviceInfo" section of the log I see the
	> following:
	> 
	>   TX param space:
	>     Nb of xmit        : 2
	>     Transmitter 0:
	>       :
	>       Nb audio channels :  10
	>       :
	>       Channel names     :
	>         IP 1
	>         IP 2
	>         :
	>     Transmitter 1:
	>       :
	>       Nb audio channels :  10
	>       :
	>       Channel names     :
	>         ADAT 1
	>         ADAT 2
	>         :
	>   RX param space:
	>     Nb of recv        : 2
	>     Receiver 0:
	>     :
	>     Receiver 1:
	>     :
	> 
	> I'm not familiar with the Saffire devices or the DICE platform in general,
	> but based on this it seems the Pro40 provides two streaming end points for
	> both tx and rx.  For both tx and rx the two endpoints clearly differ since
	> the channel names are different, so it's not like there's a bug causing
	> erroneous duplication.  With two end points FFADO requires two streaming
	> handlers and thus two IT contexts are ultimately required.  In other words,
	> this may be functioning as expected.

    The pastebin from May is no longer online, but I attached a new startup log
    from "jackd -P66 -t2000 -dfirewire -dhw:Pro4000dd28 -r48000 -p256 -n3 -v2".

So the issue that snd-dice exposes fewer channels than FFADO has been known to
me for quite a while now, but I did not send a proper report before because I
figured that the two persons who know the snd-dice code (you and Clemens) are
busy in other areas, and that I should first go read the FFADO source code in
order to learn how FFADO deals with the dual transmitters and dual receivers.
Perhaps I would thus even be able to port the necessary code to snd-dice myself.
Unfortunately, I still did not set that plan into motion.  But since you asked
now, this is what I gathered so far.
-- 
Stefan Richter
-======----- --=- --===
http://arcgraph.de/sr/