Ticket #79 (closed feature: wontfix)

Opened 13 years ago

Last modified 8 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.

03/27/12 07:49:41 changed by jwoithe

Is there any further progress on this? Does it still make sense to even try to guess a sample rate from a device given the wide variation in the way different devices handle such things? In my experience with MOTU and RME interfaces, when run on other systems it is the software on the PC which explicitly determines the rate. I don't think I've ever seen a situation where the computer software adopts to the rate of the device (probably because of the complex nature of doing this, especially when one includes devices which do sample rate conversion on digital inputs, and the like).

(follow-up: ↓ 8 ) 03/27/12 08:34:40 changed by adi

We have the same "problem" on RME MADI cards or other devices that can sync to an external clock - you always have to tell jackd about the external sample rate.

I don't know if it's even possible to open an ALSA device with an unspecified sample rate.

To sum it up:

  • it's not common
  • jackd lacks support for it
  • it would require an FFADO API extension

The only hypothetical use case I could think of is a non-jackd client that wants to open the device and then does its own SRC instead of configuring the output device to his capture or playback rate.

That said, it's very unlikely and against common practice.

(in reply to: ↑ 7 ) 03/27/12 17:07:17 changed by jwoithe

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

Replying to adi:

I don't know if it's even possible to open an ALSA device with an unspecified sample rate.

Not in a practical sense. Technically the sample rate hasn't been specified when you call snd_pcm_open(), but the resulting handle is pretty much useless until snd_pcm_hw_params() has been used to set parameters such as sample rate. I think it's probably safe to say that for all practical purposes ALSA does not include this functionality. [This is my current understanding; however, I am not an expert in the ALSA API so I'm more than happy to be corrected on this point.]

That said, it's very unlikely and against common practice.

Agreed. I'll therefore close the ticket. While following common practice is not necessarily an argument for adopting a particular approache, there seems little to be gained by striking out in a new direction for which there is no real-world use case and which is extremely difficult to implement in a usable way.