Ticket #79 (new feature)

Opened 4 years ago

Last modified 2 years ago

ffado should determine the rate from an device receiving a clock signal

Reported by: andrew hately Assigned to:
Priority: minor Milestone: FFADO 2.1
Component: Version:
Keywords: Cc:
The device the bug applies to:

Description

When running stand alone it is perfectly reasonable to tell jack the clock rate. When the device has an external clock source, for example spdif or a word clock signal, then it seems redundant to also tell ffado the clock rate; firstly it should be able to determine this from the external source and secondly if there is any difference between the external clock and the rate specified when starting jack, buffer under -runs or over-runs will result.

Change History

03/19/08 05:57:24 changed by ppalmers

  • milestone changed from FFADO 2.0 to FFADO 2.1.

postpone to 2.1. this is not as trivial as it seems.

10/09/09 13:02:00 changed by arnonym

What if jack always gets the rate from the connected device(s)? So the -r switch would be dropped and only va dbus/ffado-mixer would one change the devices samplingrate?

10/11/09 15:34:10 changed by jwoithe

Some devices in certain configurations require the software to configure the sample rate. Furthermore, some devices do not always have the ability to report the current samplerate to the software due to the assumption that it is the software which is driving the device - and that therefore the software "knows" the rate.

While samplerate could be set in ffado-mixer in these cases, my preference would still be to keep the -r switch so a sample rate can be explicitly specified by the streaming system if it so desires. To me this just seems "neater".

Another complication to consider is the case where there are multiple devices connected to the bus and they have different rates configured. Which one do you choose as the one true rate for the session? Issues like these are the things Pieter refers to when he says it's not as trivial as it first appears.

10/12/09 14:14:36 changed by arnonym

With multiple devices, shouldn't they all run at the same rate?

So what about having the -r switch optional? When its not present, ffado tries to get the rate from the device(s), when that fails it either quits with an error or assumes 49kHz (for example). When present, ffado makes sure all devices run at the given rate.

That is almost as it is now, but currently it chooses 48kHz when no -r is given and even if the device is set to another rate via ffado-mixer.

10/12/09 15:07:32 changed by jwoithe

Yes, multiple devices should run at the same rate. However, if all FFADO does is get the rate "from the device" one has an interesting problem if the multiple devices all happen to power up at different rates (which is entirely possible). Which rate would then get chosen? Since there's no easy answer to this question I am suggesting that the "-r" option should remain. I'm not saying the "-r" option becomes compulsary - I'm simply arguing that it shouldn't go away and should remain as a valid way to set FFADO's sampling rate.

I'm still not sure the "get from the device" thing will work well in the case of multiple devices if "-r" is omitted. In this case FFADO will still have to automagically choose the rate from one of the devices and there's no clear way to do this in a consistent manner. We need consistency to make the end-user experience easy to understand. So maybe the longer-term solution is to make "-r" optional in the single-device case (where the rate is fetched from the device if no "-r" is given) but manditory if there are multiple devices accessible to FFADO. But even that might be confusing for users - it really needs to be thought through.