# Feature request: channel selection and surround output



## e-t172 (Mar 3, 2010)

*Feature request: output channel selection and surround output*

Hi,

I've been using REW for quite a while now. First of all I would like to thank the author(s) for this great software  

However, something's been bugging me for quite some time now: the lack of flexibility regarding which channels REW uses for outputting its test signal. The current behavior consists of sending a stereo test signal. This is appropriate if you just want to test a stereo system in one pass. However, most of the time I test with one speaker at a time, because, well, it's the only way to make channel-specific adjustments…

With the current version (REW 5.00), if I want to test only one speaker, I must either disconnect a speaker cable, which is often difficult in final installations where connectors are hidden in some furniture, or use the Windows balance levels, which requires switching back and forth to the control panel applet each time I want to change something.

What's worse, both "solutions" can result in wrong measurements depending on where bass management is done in the chain. For example, if you disconnect the left speaker cable, bass management won't know about it, and will still send the left bass signal to the subwoofer, resulting in subwoofer output twice as loud as it should be.

Another issue is that REW doesn't support anything other than a stereo system: center and surround speakers will stay silent when the test signal is played. This is actually worse, because there is no way to circumvent this using Windows, as most audio drivers don't offer the possibility to swap/reroute arbitrary channels. This quickly becomes a real pain when your PC is connected to the amplifier via HDMI, as there is no simple way to output the test signal to the center or surround speakers apart from actually swapping speaker cables (which means accessing the back of the amplifier, unscrewing, swapping, rescrewing, etc... each time you want to test a different speaker!).

I must admit, I was a little shocked when I realized that REW is capable of doing numerous precise, sophisticated, professional audio measurements and yet is unable to do something as simple as selecting the output channel…?! That's really the only "W T F" I had with this software, but it was a big one!

So, here is my suggestion: please, make it easy to select output channels. And support 5.1/7.1 systems, too. It would probably be best to be able to change this using easily accessed checkboxes which would allow the user to choose one or several output channels he wants the test signal to be sent to.

Thanks!


----------



## JohnM (Apr 11, 2006)

*Re: Feature request: output channel selection and surround output*



e-t172 said:


> I was a little shocked when I realized that REW is capable of doing numerous precise, sophisticated, professional audio measurements and yet is unable to do something as simple as selecting the output channel…?!


Whilst one might expect or hope that selecting the output channel would be simple, unfortunately it is not. We are of course very familiar with our surround sound systems and AV processors or receivers (I'll use "receiver" for brevity), but perhaps do not give much thought to the interface to the individual channels of the system. Only the receiver has physical connection to the various channels. When it is reproducing the soundtrack of some media, such as a DVD, it is fed a compressed multi-channel stream, usually Dolby or DTS, which it decodes to generate the individual channel signals. For REW to drive the receiver in the same way it would need to be able to generate its own Dolby or DTS-encoded content. Neither Dolby nor DTS encoders are available for free. Even if REW were to acquire encoding capabilities, it would then need to generate a multichannel SPDIF signal to feed to the receiver, something few soundcards support and which is also not supported by JavaSound. On top of that, multi-channel compression schemes are not lossless, which can lead to measurement artefacts due to the effects of the compression scheme on the test signal.

There are potential approaches to supporting channel selection. One is to have encoded test signals on a CD or DVD and make measurements by manually choosing the test disc track for the required channel. Another, for systems that are driven directly from the PC (without a receiver) is to access the relevant channels directly as they are typically available to applications on the PC as a set of stereo pairs for the various channels, which can be driven by the uncompressed test signal, but such HTPC systems are still in the minority. 

As desirable as a capability for individual surround channel access is, providing it is not trivial.


----------



## e-t172 (Mar 3, 2010)

*Re: Feature request: output channel selection and surround output*



JohnM said:


> When it is reproducing the soundtrack of some media, such as a DVD, it is fed a compressed multi-channel stream, usually Dolby or DTS, which it decodes to generate the individual channel signals.


This applies to *some* systems. Arguably the majority, though that's debatable considering the REW public is not the general public.

A lot of Blu-ray players offer the option to decode the audio stream to LPCM 5.1 before sending it to the receiver (thus moving the decoding job from the receiver to the player).

Also, the vast majority of HTPC users decode DD and DTS on the HTPC, thus sending LPCM 5.1 to the receiver. Some even use an expensive soundcard for digital-to-analog conversion and thus directly connects to the amplifier (I do).

Besides, all your post is about the surround sound issue. It is indeed the main issue for me, however that doesn't mean that channel selection wouldn't be appreciable for choosing between L and R in a stereo configuration, too.



JohnM said:


> For REW to drive the receiver in the same way it would need to be able to generate its own Dolby or DTS-encoded content.


Well, you don't need to drive it *exactly* the same way. As far as I know, the receiver doesn't treat LPCM, DD and DTS streams differently: it decodes them, then applies the same bass management and other post-processing filters for all stream types. And again, this is irrelevant if you're sending LPCM 5.1 to the receiver.



JohnM said:


> Even if REW were to acquire encoding capabilities, it would then need to generate a multichannel SPDIF signal to feed to the receiver, something few soundcards support and which is also not supported by JavaSound.


"Something few soundcards support"? Eh? Go to your local PC store, then try to find ONE computer which doesn't support bitstreaming DD or DTS over SPDIF out-of-the-box. You won't find any. 99,9999% of the soundcards sold today (including integrated motherboard soundcards) support full SPDIF output.

Reasonably pricey soundcards (typical REW users), like Creative and Auzentech cards, even have features called "Dolby Digital Live" or "DTS Connect" which allow you to encode standard PCM 5.1 content from applications to DD/DTS on-the-fly and transport it over SPDIF without any software modifications. This is done by the driver or in hardware; either way, the application doesn't even know it's outputting to SPDIF, it's just outputting plain old PCM 5.1 which then gets encoded automagically by the soundcard for transport over SPDIF.

Either way, and once again, this is completely irrelevant for today's systems which use HDMI. HDMI can transport LPCM 7.1, and thus an HDMI port presents itself to Windows like any other 7.1 analog soundcard.



JohnM said:


> On top of that, multi-channel compression schemes are not lossless, which can lead to measurement artefacts due to the effects of the compression scheme on the test signal.


Again, most of the people I know use LPCM 5.1/7.1 other HDMI or analog, and thus doesn't have this kind of issues.



JohnM said:


> Another, for systems that are driven directly from the PC (without a receiver) is to access the relevant channels directly as they are typically available to applications on the PC as a set of stereo pairs


The typical modern HTPC installation will have a fully functional 5.1 PCM audio device, not a "set of stereo pairs".



JohnM said:


> but such HTPC systems are still in the minority.


No they aren't (speaking about PCM 5.1 Windows audio output).



JohnM said:


> As desirable as a capability for individual surround channel access is, providing it is not trivial.


Nowadays, yes it is. The information in your post was probably perfectly valid five years ago, but now it feels completely outdated. Virtually every HTPC owner I know has a standard PCM 5.1 audio device in Windows (HDMI or analog) and thus everything you said about DD/DTS is irrelevant to their situation.

I hope the information I'm giving you will make you change your stance on this issue.


----------



## JohnM (Apr 11, 2006)

*Re: Feature request: output channel selection and surround output*



e-t172 said:


> I hope the information I'm giving you will make you change your stance on this issue.


I'm not sure what you are trying to imply by that statement. Do you think I am somehow deliberately holding back features that could be trivially offered? Why do you think I would do that? Over the years I have put thousands of hours of software development into REW, which I provide for free. What is it you think I would have to gain?

REW is a Java application. Access to the underlying hardware is provided by the Java runtime environment. Whilst the JavaSound API can in principle support multi-channel interfaces to the hardware (and for that matter more than 16 bit sample depths) the Windows and OS X runtimes do not implement such functionality, offering only mono and stereo 16-bit interfaces. 

For Windows platforms I'll soon release a version which supports ASIO drivers, which extends the sample rates and bit depths supported to reflect the capabilities offered by the ASIO drivers rather than being limited by the JavaSound runtime support, and allows any mono channel exposed by the ASIO driver to be selected as the output. On an HTPC that would typically include all the output channels of the audio hardware, provided there is an ASIO driver available.


----------



## e-t172 (Mar 3, 2010)

*Re: Feature request: output channel selection and surround output*



JohnM said:


> e-t172 said:
> 
> 
> > I hope the information I'm giving you will make you change your stance on this issue.
> ...


Huh? I've never said that. Maybe a poor choice of words, as I'm not a native English speaker. I'm sorry.

What I was trying to say was, you seem to have made your decision not to support multichannel audio a while ago, on the basis of what the overall situation was back then. But the HTPC situation evolved since then, that's why I'm asking you to reconsider your past decision. Nothing else. I'm certainly not implying that you're deliberately harming your own project.



JohnM said:


> REW is a Java application. Access to the underlying hardware is provided by the Java runtime environment. Whilst the JavaSound API can in principle support multi-channel interfaces to the hardware (and for that matter more than 16 bit sample depths) the Windows and OS X runtimes do not implement such functionality, offering only mono and stereo 16-bit interfaces.


Oh. That's too bad  



JohnM said:


> For Windows platforms I'll soon release a version which supports ASIO drivers, which extends the sample rates and bit depths supported to reflect the capabilities offered by the ASIO drivers rather than being limited by the JavaSound runtime support, and allows any mono channel exposed by the ASIO driver to be selected as the output. On an HTPC that would typically include all the output channels of the audio hardware, provided there is an ASIO driver available.


ASIO is not supported by JavaSound, is it? So, assuming I understand this correctly, this new version will offer to choose between JavaSound and ASIO for audio output, right? Thus, I'm guessing that adding a third option which supports multichannel audio on Windows (using WASAPI, DirectSound or WaveOut as the underlying API) won't require much work then?

Implementing ASIO support would certainly be a step in the right direction. I've never used ASIO, so I'm not sure if it fully supports 5.1/7.1 audio devices. As far as I know, driver support is not really a problem since we have ASIO4ALL. I'm just hoping for a more direct layer using one of the three native Windows audio APIs so the audio output from REW doesn't have to jump through hoops before getting to the soundcard and so that it closely reproduces the sound output from a media player.

Indeed, the problem with ASIO is that it bypasses some important Windows Audio layers like the Windows mixer and sAPOs (that's the whole point of ASIO, isn't it?). This means normal applications like video players could be subject to audio filtering, whereas the REW output would not. This is good if you're just using the PC as a testing tool, but this is bad if you're also using it as a HTPC and would like to make sure the REW measurements accurately reflects what you'll be getting with a Windows application.

In particular, some audio card hardware or driver features like bass management or equalization (as commonly found in Creative and Asus sound cards) would probably be bypassed when using ASIO, which would render REW with ASIO useless to anyone wanting to use these features to calibrate the audio output of the HTPC.

That's why it would probably be best if REW could offer a "normal" mode which uses a standard Windows API for sound output (full output, not like JavaSound), and a "direct" mode which would use ASIO or WASAPI Exclusive Mode for direct, unaltered output. And for both modes, a way to select the output channel.


----------



## JohnM (Apr 11, 2006)

*Re: Feature request: output channel selection and surround output*



e-t172 said:


> I'm guessing that adding a third option which supports multichannel audio on Windows (using WASAPI, DirectSound or WaveOut as the underlying API) won't require much work then?


Unfortunately you are guessing wrong. Java is cross platform, there is always an abstraction layer between the Java application and the underlying native interfaces, principally supplied by the Java Runtime Environment. JavaSound on Windows uses DirectSound, but the features of the underlying native driver it exposes are chosen by Oracle and don't include the capabilities you would like to see. The interface to ASIO drivers will be provided by Martin Roth's JAsioHost. I am not aware of any other reliable interfaces between Java and the native hardware that provide greater access to the native capabilities of the host platform, and I've looked at quite a few.


----------



## e-t172 (Mar 3, 2010)

That's unfortunate  

Here's another idea: let's make the audio output an extension point. That is, besides JavaSound and JAsioHost, the user could choose to use a "custom" audio output. REW would then use this custom output during testing. The idea is that the "custom output" is actually an independent component which is not necessarily implemented by you, is not part of REW's code, and does not have to be implemented in Java.

This independent, third-party component, chosen and installed by the user (with maybe some bundled with REW, e.g. popular ones), could then do anything it wants with the audio data REW's feeding it: pass it to a Windows API of the user's choosing, or maybe do some more complicated things with it, like sending it over the network for playing on another device, etc. The possibilities are limitless.

Of course, one would need a clean, cross-platform, cross-framework, cross-language interface between REW and this hypothetical component. I'm suggesting a very simple interface: a component is an executable file, and you just execute it and feed it the audio data on standard input (stdin) in some well-defined audio format. No need for something complicated, for example just feed it 32-bit float with the number of channels passed on the command line, and voilà.

Because executable files and standard pipes are universal, this doesn't require platform-dependent code for you, just (possibly) for the third-party component, which isn't your concern. Besides, the interface I'm proposing is extremely simple, and could probably be implemented in something like 5 lines of code (well, without including the UI for choosing the executable file). I would happily develop a Windows audio output component, as I've already implemented applications using WASAPI in C++ several times in the past.

With a little more imagination, this could maybe prove useful for microphone input, too, although I wouldn't need it myself. Nevertheless, having both input and output as extension points could allow for interesting uses of REW, such as testing software audio components without using any hardware.

I'm just throwing ideas in the wild here, see how it goes. I would be glad to hear your impressions on this.


----------



## JohnM (Apr 11, 2006)

It is not so simple. REW needs to synchronise its capture of audio data with the generation of that data, so a simple interface fed a chunk of data with no knowledge of when (or whether) it played it would not meet the requirements - otherwise the test signal could just be saved to a WAV file and played with anything.


----------



## e-t172 (Mar 3, 2010)

Well, you're actually right. My design is flawed because it doesn't take into account that a pipe has an internal buffer (64 Ko on Linux, which would mean something like 350 ms). This means that REW cannot use blocking write operations to maintain the stream position as they would have a 350 ms latency over what the output component is actually reading (and playing).

I was quite happy with my KISS-inspired design. Too bad I'll have to complicate it just a little bit.

To fix this problem, the component would send a single byte to REW via its standard output pipe (stdout) when it's ready to play more data. Thus, the transfer loop in REW would look something like this:

- Wait for a byte from the output component
- Send a single chunk of audio data to play
- Wait for a byte from the output component
- Send the next chunk of audio data to play
- Wait for a byte from the output component
- …

There is no inherent latency with this solution aside from the chunk length used and the latency of the output component itself (the pipe latency is negligible). You're pretty much getting the same deal with JavaSound.

With this design, REW doesn't know what the preferred chunk size is. For this reason it would probably be best to use small chunk sizes (e.g. 256 samples = 1 Ko = 5 ms) so that there isn't too big a discrepancy between the output component's internal buffers and REW's.

Or you could just make the output component output a preferred buffer size on its standard output as soon as it starts so that REW know what the optimal buffer size is. Your call.


----------



## brabs (Feb 15, 2009)

No Offence to you, But John has made a program in his own time for free (he could sell it for 100's of $$) that works 100% well for the desired need. It sounds like you want him to redesign his program from scratch to make something that would cost $1000's of dollars. Based of your last post you must know a bit about code/programming etc, as I didnt understand 1 sentence of it.
Why don't you put the time in and design your own program for this?


----------



## Wayne A. Pflughaupt (Apr 13, 2006)

With all due respect, this strikes me as unnecessary, if not futile. Assuming that wanting 5.1 capability means you want to measure the main channels – typically you measure only one speaker at a time, or perhaps the front L/R together. You can’t get any meaningful measurements by measuring all speakers together. There’s no need for a 5.1 option in order to measure a single speaker. Just plug the one you want to measure into the appropriate channel of the AVR and you’ll get the measurement you want. (If you come back with “That’s too much trouble” I’m going to say you’re being lazy – heh heh! ) 

And there’s something else you apparently haven’t considered. Full-range measurements require a calibrated mic, which in turn requires a soundcard with a mic pre-amp, like the Tascam US-122 or -144, M-Audio Mobile Pre, etc. These are pro audio products and as such don’t have consumer-type 5.1 digital outputs. An alternative might be to use a stand-alone mic pre amp that can connect to one of those numerous soundcards you mentioned that have 5.1 digital outputs, but that connection between the two would be analog. So now the sound card has to _encode_ an analog signal into a 5.1 bistream before it can be sent from its 5.1 digital output. 

Regards,
Wayne


----------



## e-t172 (Mar 3, 2010)

brabs said:


> No Offence to you, But John has made a program in his own time for free (he could sell it for 100's of $$) that works 100% well for the desired need. It sounds like you want him to redesign his program from scratch to make something that would cost $1000's of dollars. Based of your last post you must know a bit about code/programming etc, as I didnt understand 1 sentence of it.
> Why don't you put the time in and design your own program for this?


Of course I don't want him to "redesign his program from scratch"... We're speaking about adding a simple feature here, a feature which would likely result in less than a few dozens lines of code (guessing here, can't say that for sure without knowing about REW's internals). This probably means something like between 4 and 8 hours of work (again, guessing).

According to you, I should develop a REW clone just so I can have this simple feature. This means I would have to reimplement all REW's measurement and analysis algorithms and UI, which is a huge undertaking (months, perhaps years of development). That's simply not comparable.

I'm not asking for much. I'm not even asking John to implement direct Windows audio output, I just want him to add an extension point to REW so I can implement Windows audio output myself! I'm trying to come up with a design here that would require as less work as possible from John just so I that I am able to implement the feature I originally requested myself. And it's not just for me: I know other people which would be quite interested by such a feature, as they also are disappointed by REW's very limited output options.

Of course if the output component interface I'm suggesting is implemented, I would be happy to give back to the community by developing and distributing a REW output component for Windows audio (WASAPI) output, free of charge, open source and all.



Wayne A. Pflughaupt said:


> Assuming that wanting 5.1 capability means you want to measure the main channels – typically you measure only one speaker at a time, or perhaps the front L/R together. You can’t get any meaningful measurements by measuring all speakers together.


Of course. I don't want to measure all channels together. I want to measure each channel seperately (L, R, C, SL, SR, LFE/Sub). That's what I've been asking for since the beginning of this topic. Please re-read my first post.



Wayne A. Pflughaupt said:


> There’s no need for a 5.1 option in order to measure a single speaker. Just plug the one you want to measure into the appropriate channel of the AVR and you’ll get the measurement you want. (If you come back with “That’s too much trouble” I’m going to say you’re being lazy – heh heh! )


That's quite a strange point of view. John made a very useful, user-friendly, easy-to-use program for making audio measurements. Asking users to access the hardware (which is sometimes difficult, if it's embedded into furniture) and switch cables EACH TIME they want to measure another channel (remember, that's 6 cable changes for each batch of measurements in a 5.1 system) completely contradicts that goal.

Besides, what you're suggesting is not always possible or correct: consider an AVR connected to the HTPC via HDMI. You can't disconnect or swap individual channel inputs from the AVR (it's one HDMI cable, so it's all channels or nothing). You could disconnect speaker cables from the AVR but that's pushing it in my opinion (unscrewing, swapping, screwing, etc... and again, for EACH measurement), and you'll get incorrect results if you consider bass management (subwoofer level will be wrong).

Again, I already explained all of this in my first post. Please re-read it.



Wayne A. Pflughaupt said:


> And there’s something else you apparently haven’t considered. Full-range measurements require a calibrated mic, which in turn requires a soundcard with a mic pre-amp, like the Tascam US-122 or -144, M-Audio Mobile Pre, etc. These are pro audio products and as such don’t have consumer-type 5.1 digital outputs. An alternative might be to use a stand-alone mic pre amp that can connect to one of those numerous soundcards you mentioned that have 5.1 digital outputs, but that connection between the two would be analog. So now the sound card has to _encode_ an analog signal into a 5.1 bistream before it can be sent from its 5.1 digital output.


Well, it seems you haven't considered that I don't use the same soundcard for output and input. I'm using the HTPC's 5.1 HDMI output for playing the test signal, and a professional M-Audio USB interface for audio input from my calibration microphone. Thus the issue you're mentioning doesn't exist.


----------



## JohnM (Apr 11, 2006)

e-t172 said:


> We're speaking about adding a simple feature here, a feature which would likely result in less than a few dozens lines of code (guessing here, can't say that for sure without knowing about REW's internals). This probably means something like between 4 and 8 hours of work (again, guessing).


Your development estimates belong in the "wild optimism" category 

Maintaining low latency audio I/O with Java is non-trivial, not least because Java threads run at lower priorities than native threads can achieve. The interface would have to run through JNI using a callback scheme, it would very quickly become an ASIO driver by another name. Since I have a solution on the way for ASIO it would seem sensible to see what needs that does and does not meet before embarking on anything else. This is a "free time" activity, if there is such a thing, so I aim to prioritise the development work to benefit the widest audience where possible. What we are discussing here is a niche within a niche and doesn't look likely to bring enough benefit to warrant the diversion from the other items on the dev list.


----------



## e-t172 (Mar 3, 2010)

I understand. Thank you for taking the time to debate this with me  

In the mean time I will investigate the ASIO4ALL alternative and see if it would possibly allow me to achieve my goal with the future REW-ASIO interface. If not maybe I'll develop an ASIO component similar to ASIO4ALL with the features I want. We'll see.

From the ASIO4ALL project page it seems that it operates using Kernel Streaming, which would be good for some use cases (direct sound card output bypassing the Windows audio engine) and bad for others (testing standard Windows applications audio output).


----------

