SPDIF bypass command from within other programme

Guillaume · Apr 16, 2003, 03:56 PM

Please have a look at this topic: http://www.hydrogenaudio.org/show.ph...ST/f/27/t/8202

**Eugene Gavrilov** · Apr 16, 2003, 05:46 PM

one can turn bypass on and off by executing kxctrl from the command line

kxctrl -shw 3 0
kxctrl -shw 3 1

there are additional controllable parameters
refer to ikx.h file in the SDK ("ids for get_hw_parameter")

/Eugene

Guillaume · Apr 17, 2003, 02:25 AM

That's perfect! Which way has the lowest 'latency' (the bypass should be turned on right after a track stops and immediately turned off again, so that the gap is minimal).

**Eugene Gavrilov** · Apr 17, 2003, 06:08 PM

I'm afraid that the latency will be rather high
I suggest you download and read the SDK -- the function of interst is iKX::set_hw_parameter

also, you could try using a 'trick' with kX mixer: save the settings file with the only one checkbox enabled -- 'HW Parameters'. if you save two separate *.kx settings files (the one with 'bypass' enabled, and the other - with disabled), you'll be able to load them on-the-fly by executing: kxmixer --shell --load-settings <file_name>

calling "kxmixer --shell ..." is much faster than running kxctrl

/Eugene

kode54 · Apr 18, 2003, 12:31 AM

As I just realized myself and indicated in that topic, there is no easy way to code a plug-in which will do this and also account for output latency.

**Eugene Gavrilov** · Apr 18, 2003, 01:57 AM

>> latency

unless you use ikX::get_hw_parameter directly

/Eugene

kode54 · Apr 18, 2003, 02:42 AM

I wasn't referring to latency of executing the command, but latency in the player plug-in which will be triggering this effect. If coded as a DSP, it will receive end-of-track signal as an audio file finishes playing, but at that moment, there will still be an unknown amount of sample chunks from the end of that file waiting in queue for the DSP processing call that receives EOT signal. Not only that, but the output plug-in will also have a full buffer until those samples are processed and flushed. So, with an output latency of 1000ms, the bypass signal may be triggered as much as 1 second before the actual end of track reaches the SPDIF.

It could be coded as a new output plug-in, but I'm not sure if outputs are flushed between tracks or not... might not if they're the same sample rate, or if user has enabled a resampling DSP. Oh, the complications.

Guillaume · Apr 18, 2003, 03:26 AM

Quote:

Originally posted by kode54
I wasn't referring to latency of executing the command, but latency in the player plug-in which will be triggering this effect. If coded as a DSP, it will receive end-of-track signal as an audio file finishes playing, but at that moment, there will still be an unknown amount of sample chunks from the end of that file waiting in queue for the DSP processing call that receives EOT signal. Not only that, but the output plug-in will also have a full buffer until those samples are processed and flushed. So, with an output latency of 1000ms, the bypass signal may be triggered as much as 1 second before the actual end of track reaches the SPDIF.

It could be coded as a new output plug-in, but I'm not sure if outputs are flushed between tracks or not... might not if they're the same sample rate, or if user has enabled a resampling DSP. Oh, the complications.

That latency of 1000ms you're talking about, is this exactly the same as the buffer size? Shouldn't the plugin be able to delay the ikX::get_hw_parameter command exactly as the time the buffer is set to (could be manually entered into plugin config or got from active output plugin config)???