SPDIF bypass command from within other programme

Guillaume · Apr 16, 2003, 09: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, 11: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, 08: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 18, 2003, 12:08 AM

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, 06: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, 07:57 AM

>> latency

unless you use ikX::get_hw_parameter directly

/Eugene

kode54 · Apr 18, 2003, 08: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, 09: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)???

Apr 16, 2003, 09:56 PM	#1
Guillaume DriverHeaven Junior Member Join Date: Jul 2002 Location: Netherlands Posts: 24 Rep Power: 0	SPDIF bypass command from within other programme Please have a look at this topic: http://www.hydrogenaudio.org/show.ph...ST/f/27/t/8202 __________________ Listen to Guillaume I see seven towers, but I only see one way out... AMD Athlon 1,2GHz, 512MB Ram PC133 (M.teq), Asus A7V133, 160GB WD + 20GB WD, Sapphire Radeon 9600XT, Creative SB Audigy 1394, Hoontech SB DBII Bracket, Pioneer 106D DVD-writer, Plextor 12/10/32A CD-RW, Iiyama ProLite E481S

Apr 17, 2003, 08:25 AM	Thread Starter #3
Guillaume DriverHeaven Junior Member Join Date: Jul 2002 Location: Netherlands Posts: 24 Rep Power: 0	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). __________________ Listen to Guillaume I see seven towers, but I only see one way out... AMD Athlon 1,2GHz, 512MB Ram PC133 (M.teq), Asus A7V133, 160GB WD + 20GB WD, Sapphire Radeon 9600XT, Creative SB Audigy 1394, Hoontech SB DBII Bracket, Pioneer 106D DVD-writer, Plextor 12/10/32A CD-RW, Iiyama ProLite E481S

Apr 16, 2003, 11:46 PM	#2
Eugene Gavrilov kX Project Lead Programmer and Coordinator Join Date: Dec 2002 Posts: 3,119 Rep Power: 75	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

Apr 18, 2003, 12:08 AM	#4
Eugene Gavrilov kX Project Lead Programmer and Coordinator Join Date: Dec 2002 Posts: 3,119 Rep Power: 75	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

Apr 18, 2003, 06:31 AM	#5
kode54 DriverHeaven Junior Member Join Date: Oct 2002 Posts: 30 Rep Power: 0	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.

Apr 18, 2003, 07:57 AM	#6
Eugene Gavrilov kX Project Lead Programmer and Coordinator Join Date: Dec 2002 Posts: 3,119 Rep Power: 75	>> latency unless you use ikX::get_hw_parameter directly /Eugene

Apr 18, 2003, 08:42 AM	#7
kode54 DriverHeaven Junior Member Join Date: Oct 2002 Posts: 30 Rep Power: 0	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.