Yes.

Thanks. Then your Solo 1st gen is not affected. If I understand the patch correctly, the 2nd gens Audiointerfaces report to the snd-usb-driver mistakenly, that SYNC should be used. The patch tries to override this and forces ASYNC anyway:

+    /*
+     * Focusrite Scarlett Solo 2nd generation
+     * Reports that playback should use Synch: Synchronous
+     * while still providing a feedback endpoint. Synchronous causes
+     * snapping on some sample rates.
+     * Force it to use Synch: Asynchronous.
+     */
   

My guess is, that Pianoteq has to use the system timer (/dev/tsc), because /dev/rtc and /dev/hpet are not available on all platforms.

PTQ's audio output just talks with JACK in my setup. If a clock is needed for this audio transfer, I assume it is the system timer.

The sound could be degraded, when the DAC in the USB-Soundcard is synchronized with the system timer, which is the case in synchronous mode between ALSA and the soundcard. The less jitter / higher accuracy the system timer has, the better the "HiFi" I suppose.

Not much time at the moment, but indeed some quirks exist with the 2nd generation of Focusrite Scarlett Solo and 2i2 in the ALSA usb-audio driver:

https://mailman.alsa-project.org/piperm...47832.html

Gasparka, are you having the Scarlett Solo 1st gen?

Yes.
Also, you could upload here your bad and good audio sample - if i don't hear any difference then it is sure that problem is in your USB chain...or i am bad eared.
I am wondering if it is possible that Pianoteq uses the inaccurate system clock and thus the output has bad clock jitter.

https://mailman.alsa-project.org/piperm...47832.html

Gasparka, are you having the Scarlett Solo 1st gen?

Interesting that you are forced into SYNC mode - still i think this is the source of your problems.

Yes, that's strange. Even playing Wavs from Audacity via raw ALSA my 2i2 2nd gen is always a SYNC endpoint. Normally I would expect ASYNC in playback direction like in your Scarlett Solo. Hm.

Hope I have time to look at it tomorrow.

Thanks

gasparka wrote:

Wondering what happens if you disable the synchronous mode?

I made a few tests in 2018 here:
https://forum.modartt.com/viewtopic.php...73#p955773
In jackd's synchronous mode the latency had been minimal better than in the default asynchronous mode. Theoretical background had been an information I found in the manpage of jack_iodelay, but don't know if it is correct today:

"Note that JACK2 will add an implicit additional period when using the default asynchronous mode, so for JACK1 or JACK2 in synchronous mode, the buffer size is n*p, but for JACK2 in asynchronous mode the buffer size is (n+1)*p." -

I want to keep the latency on my hardware as low as possible, which means I always prefer the minimum of 2 periods.

As of my understanding, in synchronous mode the system clock drives the full audio playback chain - it overrides the accurate clock in your Focusrite 2i2 gen2.

https://www.hifi-advice.com/blog/audiop...nchronous/

Maybe the sync/async modes just handle the dataflow between JACK and ALSA? (don't know)
Is the sync between ALSA and USB-Focusrite another story eventually? Don't know too, but there is an indicator that the Focusrite is always driven synchronous (SYNC), because it never changes ->

cat /proc/asound/card1/stream0
Focusrite Scarlett 2i2 USB at usb-0000:00:15.0-1, high speed : USB Audio

Playback:
  Status: Running
    Interface = 1
    Altset = 1
    Packet Size = 56
    Momentary freq = 44100 Hz (0x5.8333)
  Interface 1
    Altset 1
    Format: S32_LE
    Channels: 2
    Endpoint: 1 OUT (SYNC)
    Rates: 44100, 48000, 88200, 96000, 176400, 192000
    Data packet interval: 125 us

Capture:
  Status: Stop
  Interface 2
    Altset 1
    Format: S32_LE
    Channels: 2
    Endpoint: 2 IN (ASYNC)
    Rates: 44100, 48000, 88200, 96000, 176400, 192000
    Data packet interval: 125 us

cat /proc/asound/card1/pcm0p/sub0/hw_params
access: MMAP_INTERLEAVED                                                                                         
format: S32_LE                                                                                                   
subformat: STD                                                                                                   
channels: 2                                                                                                     
rate: 44100 (44100/1)                                                                                           
period_size: 64
buffer_size: 128

But more back to the topic again. My point was the change of audio quality using different clocksources in JACK, not latency. Using the HPET source for example changes the audio-quality, no matter whether I'm using 2 or 3 periods of 64 samples as buffer in JACK. It is not clear to me, if this is theoretically possible.

Interesting that you are forced into SYNC mode - still i think this is the source of your problems. I have similar card:

cat /proc/asound/card1/stream0
Focusrite Scarlett Solo USB at usb-0000:00:14.0-4, high speed : USB Audio

Playback:
  Status: Running
    Interface = 1
    Altset = 1
    Packet Size = 72
    Momentary freq = 48000 Hz (0x6.0000)
    Feedback Format = 16.16
  Interface 1
    Altset 1
    Format: S32_LE
    Channels: 2
    Endpoint: 1 OUT (ASYNC)
    Rates: 44100, 48000, 88200, 96000, 176400, 192000
    Data packet interval: 125 us
    Bits: 0

Capture:
  Status: Running
    Interface = 2
    Altset = 1
    Packet Size = 72
    Momentary freq = 48000 Hz (0x6.0000)
  Interface 2
    Altset 1
    Format: S32_LE
    Channels: 2
    Endpoint: 2 IN (ASYNC)
    Rates: 44100, 48000, 88200, 96000, 176400, 192000
    Data packet interval: 125 us
    Bits: 0

Timer frequency (250 Hz) -> (1000 Hz)

The diff in the config is now:

$ diff /boot/config-4.9.0-11-rt-amd64 linux-source-4.9/.config
596c596
< CONFIG_HZ_250=y
---
> # CONFIG_HZ_250 is not set
598,599c598,599
< # CONFIG_HZ_1000 is not set
< CONFIG_HZ=250
---
> CONFIG_HZ_1000=y
> CONFIG_HZ=1000

Result: The best Pianoteq experience I ever had on that Laptop!

The audio quality is excellent now with the system timer. No need for the auxiliary HPET-clock any longer.

The response of PTQ is snappy and free of glitches.

PTQ v6.6.0 with 64 samples, JACK in synchronous mode with 64 samples and 2 periods, Focusrite Scarlett 2i2 2nd gen as synchronous ALSA USB-Endpoint.

(/usr/bin/jackd -S -p128 -dalsa -dhw:USB -r44100 -p64 -n2 -P)

I don't know, why the Debian Project decided for 250 Hz in their Realtime-Kernel, maybe they had servers and embedded systems in mind. But for us realtime linuxmusicians 1000 Hz seems to be the far better option.

cheers

My point about Alsa/Jack is that Jack uses Alsa so anything that is done in Jack can be directly done in Alsa.  So you could directly run 2 periods in Alsa.

How?
PIanoteq v6.6.0 README_LINUX.txt  ->
"With the Alsa driver, the latency is 3 times the buffer size (a buffer of 64 samples at 44100Hz gives a latency of 4.3 ms)."

See https://forum.modartt.com/viewtopic.php...80#p955780

Does JACK not have better realtime scheduling with PTQ than ALSA?

:-)

Wondering what happens if you disable the synchronous mode?

I made a few tests in 2018 here:
https://forum.modartt.com/viewtopic.php...73#p955773
In jackd's synchronous mode the latency had been minimal better than in the default asynchronous mode. Theoretical background had been an information I found in the manpage of jack_iodelay, but don't know if it is correct today:

"Note that JACK2 will add an implicit additional period when using the default asynchronous mode, so for JACK1 or JACK2 in synchronous mode, the buffer size is n*p, but for JACK2 in asynchronous mode the buffer size is (n+1)*p." -

I want to keep the latency on my hardware as low as possible, which means I always prefer the minimum of 2 periods.

Maybe the sync/async modes just handle the dataflow between JACK and ALSA? (don't know)
Is the sync between ALSA and USB-Focusrite another story eventually? Don't know too, but there is an indicator that the Focusrite is always driven synchronous (SYNC), because it never changes ->

cat /proc/asound/card1/stream0
Focusrite Scarlett 2i2 USB at usb-0000:00:15.0-1, high speed : USB Audio

Playback:
  Status: Running
    Interface = 1
    Altset = 1
    Packet Size = 56
    Momentary freq = 44100 Hz (0x5.8333)
  Interface 1
    Altset 1
    Format: S32_LE
    Channels: 2
    Endpoint: 1 OUT (SYNC)
    Rates: 44100, 48000, 88200, 96000, 176400, 192000
    Data packet interval: 125 us

Capture:
  Status: Stop
  Interface 2
    Altset 1
    Format: S32_LE
    Channels: 2
    Endpoint: 2 IN (ASYNC)
    Rates: 44100, 48000, 88200, 96000, 176400, 192000
    Data packet interval: 125 us

cat /proc/asound/card1/pcm0p/sub0/hw_params
access: MMAP_INTERLEAVED                                                                                         
format: S32_LE                                                                                                   
subformat: STD                                                                                                   
channels: 2                                                                                                     
rate: 44100 (44100/1)                                                                                           
period_size: 64
buffer_size: 128

But more back to the topic again. My point was the change of audio quality using different clocksources in JACK, not latency. Using the HPET source for example changes the audio-quality, no matter whether I'm using 2 or 3 periods of 64 samples as buffer in JACK. It is not clear to me, if this is theoretically possible.

As to your HPET questions, I would pose them at https://www.linuxmusicians.com/ where there are more linux experts

https://www.hifi-advice.com/blog/audiop...nchronous/

Concerning HPET timers check out https://wiki.linuxaudio.org/wiki/system...sysctlconf

Yes, I knew that link. What exactly is your point?

What do you mean? Where?

Also you have a misunderstanding about Jack and Alsa.   Alsa is the driver which directly communicates with audio hardware.   Jack is an audio server that uses Alsa (or FFADO for firewire devices) to communicate with audio hardware.   Jack offers some advantages to over using Alsa: easier to configure, allows communication between different audio programs.    Here is some good reading:  https://www.libremusicproduction.com/ar...-jack.html

Normally I'm using Pianoteq with audio output JACK, which itself redirects to ALSA's driver snd-usb-audio and an USB connected Focusrite 2i2 gen2.

I'm using JACK because it supports 2 periods (instead of 3 periods at direct ALSA) of 64 samples buffers in it's synchronous mode (option jackd -S). Slightly better latency.

So far so good.

Recently I saw that JACK has an option -c to select an available clocksource. Default is the System timer and the other is the HPET timer (High Precision Event Timer). HPET is a hardware timer available on most Intel boards.

When I select HPET (-ch) the audio quality is better than with the standard system timer on my Laptop. More defined, clearer, less tendency of dullness.

I didn't expect that, because I thought the hardware clocks like RTC or the newer HPET are obsolete with contemporary "tickless" kernels.

My vague guess is, that HPET has a better resolution and higher precision than my standard system timer, so that all audio transfers between PTQ, JACK, ALSA, USB-Audio have less latency and jitter. - But I'm not sure if those assumptions have a theoretical background or I just became a victim of the placebo-effect.

Maybe the Debian Realtime-Kernel is not so tickless (dynamically clocking) than I thought. For example ALSA tries to use static timers at 250 Hz (<=> 4000 µs):

# cat /proc/asound/timers
G0: system timer : 4000.000us (10000000 ticks)
[...]

While the HPET is adjusted at 1024 Hz at the moment:

# cat /proc/sys/dev/hpet/max-user-freq
1024

Eventually recompiling my kernel with CONFIG_HZ_1000=y (instead of default CONFIG_HZ_250=y) would have the same effect as using the HPET clock. Dont' know. But it would be uncomfortable to recompile the kernel each time a new is released. At the moment I just use the updated Realtime-kernels of my Linux-distribution.

Maybe someone (PTQ-crew itself?) is able to shed some light how tickless kernels and (pseudo?)static clocksources like 250 Hz or 1000 Hz go together.

Thank you

System info: Debian 9 ("Stretch"), kernel 4.9.0-11-rt-amd64, Pianoteq 6.6.0 Standard