Recent content by phofman

@Sonnie: Just a few notes. Looking at your config - * Have you considered using WASAPI exclusive? * Do you actually need the ASIO/FlexASIO? You have two separate devices which for merging in ASIO is not good (splitting to two devices is a hack implemented by the ASIO bridges, but ASIO was not...

Maybe the REW installer does create those temp hexa-name files and your system creates them in a way that they cannot be removed subsequently. Maybe the names mess with the path somehow, the windows file subsystem creates them somewhere else, and the subsequent delete call fails to locate them.

You can check your Juli@ health by booting into any linux distribution (e.g. Ubuntu or Mint) installed on a flash drive. The Juli@ driver is always present in linux kernel and the card will work out of the box, if electrically OK.

Do you feed some SPDIF stream into the interface when set to SPDIF clock? If not, then probably the device is not freewheeling when set the SPDIF clock. The buffer under/overrun issue seems to affect that specific hardware/driver...

For capture rate it's quite obvious. Actually I meant the somewhat more complex effect on the playback rate. If a device supports switching to incoming SPDIF clock and supports only common capture and playback rate, then the playback part runs at the same samplerate as the capture which is...

I am afraid I do not understand "Normal java drivers" communicate through the windows audio layer which can do many things, more than what you see in the GUI. Whereas the wasapi exclusive access talks directly to the driver, no resampling, no stream merging, no sample conversion. Well, the...

I would try setting a different device as capture default, to make sure the windows subsystem does not block the card (despite those "exclusive" checkboxes which may or may not work). Also I would check that really no other software is accessing the device (e.g. some other ASIO bridge like...

If ASIO4All is running at the same time and the card is selected, it could be blocking the card for itself.

I would really recommend to avoid jack in the chain with REW. That would make a similarly convoluted chain like the thread discussed above. IMO the jack javasound connector is rarely tested. The 2.5" drives - 128GB SSDs are almost for free :-)

Well, that thread deals with measuring impulse response at 192kHz with a device which accepts only 48kHz, plus insisting on using pulseaudio javasound driver. That's an extremely convoluted setup.

If you have your device working fine in linux, IMO there is no reason for REW not to work in linux, if you prefer it to windows. Just make sure you disable your audio devices used by REW in pulseaudio/pipewire, and use the javasound alsa output (plughw). If needed to use a PCM device defined by...

Long FFT means : * the overall frequency band gets split into more bins and * more samples are required for the calculation Now the problem of asynchronous playback/capture is that as time passes the sampling may drift against the generation. E.g. the generator outputs e.g. 1kHz (as measured...

As John has already noted - using a device with common clock for playback and capture. Or using devices which can have their clocks synchronized externally. None of that is the case of your Cosmos ADC. But maybe the clock drift tracking can be done in REW for multitone somehow too, that's a...

Maybe it's more difficult to keep track of the frequency shift and especially adjust the calculation accordingly for multitone than for a single sine. IMO these long precise measurements are better to do with synchronized generation/capture.

@Quickmcj : Dropouts are very easy to check in RTA with averaging. Every dropout ruins the averaged chart.