I'm sorry but I do not understand why I have to set the correct samplerate first. As I simply do not know it in advance.
In my understanding I set the soundcard to sync for the spdif input. Indeed the input status shows the correct samplerate.
So how do I get the input status samplerate information by the ASIO interface? I do not need to set the samplerate by myself but just to follow the samplerate reported by the soundcard for further processing.

Why to measure the time it needs for the samples when the soundcard already has the information available?

Your answer sounds very restricted.

Anyway it seems that your ASIO interface does not follow the Steinberg ASIO SDK 2.2 specification:

ASIOError ASIOGetSampleRate(ASIOSampleRate *currentRate);
Purpose:
Get the current sample Rate.
--> reports the wrong samplerate

Purpose:
Set the hardware to the requested sample Rate. If sampleRate == 0, enable external sync.
--> does not allow to select sampleRate = 0, it returns ASE_NoClock

The spdif interface is not a SMUX multiplexed interface (of course with ADAT your argument maybe/is ok).

A samplerate converter introduces a signal weakening by additional brickwall filtering. Thus IMO it should be avoided if not really necessary. Furthermore also the samplerate converter has to detect the correct input samplerate, so you just shift the problem to another device.

The FF400 control panel shows the correct samplerate in the input status. Thus it must have already detected the samplerate. You have not answered why the information is not available for the host application. It should be at least valid in case of selecting spdif as an external clock source.

How do usual "stupid" DA-converters connected to the spdif output of the FF400 detect the current samplerate for the correct conversion? They show the detected samplerate on the display and the user has not to set the samplerate first.

BTW I remember that with Linux and ALSA also the correct samplerate is shown (e.g. with HDSP9652 soundcard by amixer cget iface=MIXER,name='External Rate'). Isn't there a way with Windows?

Thanks for your patience.

BR
Uli

1. Let's forget for a moment ASIO. Let's try to use the FF400 just as a DA converter. So I can select spdif as clock source and forward the spdif input to an analog output. Finally the setup is stored in the flash memory. Then no further computer is in the game. An external spdif source is connected. Does the FF400 now support all samplerates for DA conversion? Like a usual DA converter?

2. Of course an ASIO recording must stop when the samplerate changes. No doubt about. This is exactly my question. I like to detect the samplerate change and to stop the recording of course and finally to restart it with the new correct samplerate (basically the task is to filter the input data and to send them to the outputs, e.g. multi-way crossover application. The filter kernel must change according to the samplerate).

When the input samplerate is 48 kHz first and then 96 kHz actually the ASIO driver does not detect a samplerate change. ASIOGetSampleRate still reports 48 kHz. The control panel shows 96 kHz as input status. So if I could get this information correctly then I can do all the proper actions to restart the filter job correctly.

Is it so difficult to understand or to carry out? Your control panel already proves that the soundcard knows about the correct samplerate.

BR
Uli

PS: I cannot force a user to use AD/DA instead of a digital input signal, indeed the additional conversion will produce additional faults.

This morning I have carried out a simple test by creating two logsweeps with 48 kHz and 96 kHz samplerate (sweep from 10 Hz to fs/2). The sweeps are fed to the spdif input of the FF400 by an external player. The sync is set to spdif and the clock mode samplerate to 48000. In the matrix the spdif input is directly connected to the phones output. So no other application is in the game.

Result 1: playing the 48 kHz sweep is ok. The input status shows 48 kHz. Everything fine
Result 2: playing the 96 kHz sweep leads to clearly audible aliasing in the high frequency range. The input status shows 96 kHz. But the DA-conversion is still done @48 kHz. That's why the aliasing occurs.
Result 3: setting the clock mode to 96000 and playing the 96 kHz sweep does not create the aliasing.

Summary 1: the soundcard is not able to run as a true slave. It expects to have set the clock mode samplerate correctly. Thus the soundcard cannot run as an unattended standalone DA-converter !
Summary 2: the soundcard still detects the input samplerate and displays it in the control panel. But it cannot switch itself to this samplerate. It seems that RME cannot escape because of the design principles (SMUX with ADAT including the change of channel numbers).
Summary 3: thus it is mandatory (with all RME soundcards?) to set the clock mode samplerate by the user or by the application (as already nailed down by MC and DF)
Summary 4: if an application does not know of the input samplerate in advance it will set a wrong clock mode by 100% chance (as long as the source is not restricted to a certain range of samplerates). To get a correct behaviour the application must know about the actual samplerate (as reported in the input status). Then the application can stop the recording, set the correct clock mode samplerate and restart the recording.
Summary 5: the application cannot detect the correct input samplerate by itself. It must get the information from the soundcard. The soundcard has the information at least (see input status). This leads to the final big question: how can the application get the correct samplerate information from the soundcard driver?

Regards
Uli

Hello Daniel,

please imagine a following setup:

The task is to establish an active crossover network with a PC. The PC has a soundcard. You may consider it as a blackbox with spdif input and 6 analog outputs (3-way stereo setup).

Thus the blackbox will receive a spdif signal from an external source. The signal gets filtered by the application in the blackbox. The result will be sent to the outputs. That's all.
Is this task so unusual?

Our problem is the samplerate of the spdif signal. The blackbox shall/must allow all samplerates. The application takes care about and applies the correct XO filters. IMHO this is not a very special requirement.

The task can be easily solved if the application knows about the true samplerate.

So the communication protocol between the soundcard driver and the application must allow to share the information. The ASIO protocol has commands like ASIOGetSamplerate for this purpose. But the RME ASIO driver sends the wrong information. This is what I'm complaining about. I do not have access to the driver software and so I cannot correct it by myself.

Of course stopping and restarting is my problem then. It does not create a problem as it works fine already e.g. with a samplerate switch between 44.1 and 48 kHz.
I simply cannot use the application for all samplerates as I do not get the correct info for all samplerate switches.

Best regards
Uli

PS:
Please accept that the described task is different from other applications like Cubase and Samplitude.
Please accept that a blackbox user likes to feed the blackbox with 44/16 music but also with 96/24 tracks.
Please accept that the users do not want to buy an ADI192DD for each setup but just use the soundcard.

I have feared your answer as it may kill an application.

Obviously the Fireface Settings displays the input status, it must connect to the soundcard. Is there a chance for the application to connect in a similar way just to get the missed information? A very bad but possible solution is to run Fireface Settings concurrently with the application, to read its window content by EnumChildWindows and to extract the samplerate (I've tried it, it is possible. But the window has to be kept open and the samplerate has to be listed with each soundcard. This is not safe anyway). A direct communication API would be much better. It even does not screw up other routines as it just takes the missed samplerate info.

Regards
Uli

BTW just another example what users might expect but reality is different:
Take Foobar with ASIO and create a playlist with tracks of mixed samplerates. A user simply expects that all tracks are played correctly. Foobar also knows about the required samplerate as the track info contains it. So Foobar also tries to switch the samplerate. Even from 44.1 to 96. But then the output stops. You can only start it by stopping the playback and restarting. The fault now is on the side of Foobar. The application programmer must know that simply switching the samplerate of RME soundcards does not work. The ASIO driver has to be stopped and restarted.
Of course its only non-professional customers using Foobar ;-)