From: Jonathan W. <jw...@ju...> - 2013-08-18 13:47:00
|
Hi Ilia > >Further to my earlier email, could you please repeat the usual test on your > >laptop with the latest svn revision (r2373 or later)? ... > > No problem! > > """ > : > 1376818443061076: Debug (fireface_flash.cpp)[ 281] read_device_flash_settings: Device flash settings: > 1376818443061107: Debug (fireface_flash.cpp)[ 286] read_device_flash_settings: Clock mode: Slave > 1376818443061114: Debug (fireface_flash.cpp)[ 294] read_device_flash_settings: Sample rate: 192000 Hz (DDS active) > 1376818443061139: Debug (fireface_flash.cpp)[ 373] read_device_flash_settings: Settings acquired from flash: > : > 1376818443061209: Debug (fireface_flash.cpp)[ 407] read_device_flash_settings: sample rate: 192000 > : > 1376818443172166: Debug (devicemanager.cpp)[ 796] initStreaming: Setting samplerate to 48000 for (0x26b38f0) > 1376818443172252: Debug (fireface_hw.cpp)[ 331] get_hardware_state: State reported by hardware: > 1376818443172270: Debug (fireface_hw.cpp)[ 332] get_hardware_state: is_streaming: 0 > 1376818443172276: Debug (fireface_hw.cpp)[ 333] get_hardware_state: clock_mode: autosync/slave > 1376818443172285: Debug (fireface_hw.cpp)[ 334] get_hardware_state: autosync source: 0 > 1376818443172290: Debug (fireface_hw.cpp)[ 335] get_hardware_state: autosync freq: 0 > 1376818443172302: Debug (fireface_hw.cpp)[ 336] get_hardware_state: spdif freq: 0 > 1376818443172306: Debug (fireface_hw.cpp)[ 337] get_hardware_state: ADAT 1/2 status: 0, 0 > 1376818443172322: Debug (fireface_hw.cpp)[ 338] get_hardware_state: SDPIF status: 0 > 1376818443172328: Debug (fireface_hw.cpp)[ 339] get_hardware_state: Wclk/tco status: 0, 0 Thanks for this. That is pretty much what I was expecting to see - it's nice to have it confirmed. > >Based on your earlier debug output it seems your FF800 is in slave > >(autosync) clock mode. It appears that FFADO has a logic error when it > >comes to dealing with devices in slave mode (perhaps among other things). > >Once I've confirmed some details about the way your FF800 is set up I expect > >the fix to be reasonably easy. > > I also confirm, as you ask, that I am shure that my latest test on windows > before I made previous linux debug output was at 192kHz in slave mode! Excellent - that's good to know. I have done further investigation and there were a number of logic errors in the code which dealt with the setting of the sample rate. An errant return value in setSamplingFrequency() (fixed in r2374) is almost certainly the reason why FFADO kept going with the 48 kHz setting even with the device set to 192 kHz. An inconsistency in the way explicit sampling rates were handled (fixed in r2376) probably explains most of the failures you had when trying to reset the sampling rate via ffado-mixer and jackd itself. r2376 also fixes a few other problems associated with the explicit frequency functionality. In short, while the low level driver code has some support for this the rest of FFADO doesn't expose it to the user, so anything the driver does which presupposes user interaction is really invalid at this time. There are still some rough edges to smooth out in relation to the clock control, but they can wait until later. About the only symptom of yours that I'm not sure about dates from the very early round of tests. The verbose log from the 48 kHz test that you reported to the list indicated that the device was instead running at or around 44.1 kHz. Given what I've now deduced I can see how this could be possible. However, you mentioned that you also tried running at 44.1 kHz which in theory should have worked. Maybe it was in slave clock mode then and either there was no clock available or it was the wrong rate. In any case I'm going to leave this to one side for the moment pending the outcome of the next round of tests (see below). > Also I have a new good new, I thout that if my soundcard configured as > slave at 192 kHZ, I must run It in this mod. I connect ext. SPDIF with > 192KHz signal, set jackd -r 192000 option, and plays with -n and -p, It > start with -p 4096 and -n 6 with lot of x runs, but I got to run qjackctl > player and play some clicking sound to RME phones out! Unfortunately it > continues only for 1 minute and that jackd died, I not saved output, And > it is not start again with same parameters. Thanks for this report - it is helpful to hear this as it further confirms my theories about what's been going on. I am a little surprised to see that you needed "-p 4096 and -n 6" to make this even vaguely functional, but we can revisit that later (in particular, I'm not sure the kernel firewire drivers can handle "-p 4096). At this stage I would like you to try r2376 and see what happens. I expect that running jackd at its default rate (48 kHz) will now cause the device to be set up to run at 48 kHz regardless of the rate programmed into flash (currently 192 kHz in your case). The verbose logs will confirm this. It *may* even stream audio correctly now, but only by testing can be determine that. The outcome of your tests in r2376 will determine our next move. I should note that I'm not sure what ffado will do if the FF800 is set up for slave (autosync) clock operation but there's no valid clock being received. If you want to keep the device in slave mode, it would be best to ensure that it's being fed with a clock (whose frequency matches that to be used by jack) *before* you start jackd. Either that or use ffado-mixer to switch to "master" clock mode for this round of testing. Regards jonathan |