output device selection?

[0xDiddi]

What would be involved in enabling support for selecting different audio devices?

[hajimehoshi]

Makes sense.

In some environments like browsers, there is no way to choose audio devices.

[0xDiddi]

I have looked around the underlying windows library and it seems pretty straight forward

• waveOutOpen takes a device id. This is currently set to WAVE_MAPPER which selects a device with "the appropriate capabilities".
• there is waveOutGetNumDevs which returns the number of available audio devices
• I'm not sure if the device id is just its index or if there is some mapping. I have however seen no function that would facilitate such a mapping.
• there is waveOutGetDevCaps which, for a given device id, returns its capabilities and its name, which would allow for "search by name" functionality

I'll give this a shot and see how it goes.

---

Another question is that of the API. I suppose this functionality looks roughly similar on other platforms that support multiple devices, but the question is in what way this should be exposed.

Some thoughts:

• The current behaviour should remain the default, no matter what, as to not break dependent projects.
• I'd suggest a GetDevices() function that returns a slice of device structs. These would roughly be a translation of the WAVEOUTCAPS capability struct, containing the devices name, id, and potentially other relevant information
• A SetDevice() function that takes either the id or the device struct, and does the necessary api calls

[0xDiddi]

I realized a small oversight in my previous idea of a SetDevice() function: at least on windows, the device must be specified when first opening the device, and can't (afaict) be changed later on.

This means we'd need another variant for newDriver and subsequently also for NewPlayer that takes the device selection into account.

Alternatively it would be an option to re-create the driver every time the device is changed. This sounds like kind of a bad idea, but then again device selection would usually be a one-time setup call so it might not be all that bad.

[hajimehoshi]

I am now working on introducing 'context' #47 to create multiple players. Perhaps, we should use the term 'device' instead of 'context'.

Alternatively it would be an option to re-create the driver every time the device is changed.

I tend to agree. What is an actual use case when the user wants to change the device?

[Asday]

Occasionally, Path of Exile gets confused and tries to play its sound out of my screen through HDMI. I then have to go to its settings pane and flick it back to my DAC.

EDIT: Also back when I had multiple DACs, applications would generally open and use my default device as specified in the Windows settings, and I'd need to go into their settings (if possible) and switch them to the DAC I wanted them on. These DACs were then connected to a mixer, which sent some of them to one output, and all of them to the other, which let me do things like stream while listening to music, without the music being played on stream.

[0xDiddi]

which let me do things like stream while listening to music, without the music being played on stream.

My use case is kinda similar: I have my speakers as the default device, and then I have a virtual audio cable which I use in combination with a rigged VLC player as a sort of soundboard in VOIP apps.

I was looking to program a custom soundboard app which would of course need to send its output to the virtual audio cable and not my speakers.

My program would likely be a console application, so the configuration would be either a config file or command line option, but either way it would be a one-time setup at startup. Given that go hasn't found it's way into all that many ui applications, I'd guess that'd be the same for most other apps as well.

---

Perhaps, we should use the term 'device' instead of 'context'.

That seems to me like the more descriptive term. Given what you said in #47, at that point we could also add another parameter to the constructor in addition to channels, size and sample rate that would specify the physical device.

This constructor could then also internally check if an object for that device has already been created and throw an error if necessary.

[0xDiddi]

So I finally found the time to experiment around a bit and found the following:

• waveOutGetNumDevs() works fine (returns the correct number of devices)
  • The device id used by the API is a number between 0 and the value returned by waveOutGetNumDevs()
• regarding waveOutGetDevCaps
  • there are two variants: waveOutGetDevCapsA and waveOutGetDevCapsW. After looking into the header file, the W variant is for wide characters in the device name. I'd assume that sticking to 8 bits width with the A variant should be sufficient then.
  • calling both with either width returns a mmresult of 11, which means invalid arguments, but I have no idea where the error is

My current code looks like this:

var caps *waveoutcaps
var id int = 5 // actually a parameter

r, _, e := procWaveOutGetDevCaps.Call(uintptr(id), uintptr(unsafe.Pointer(caps)), unsafe.Sizeof(waveoutcaps{}))

[hajimehoshi]

• there are two variants: waveOutGetDevCapsA and waveOutGetDevCapsW. After looking into the header file, the W variant is for wide characters in the device name. I'd assume that sticking to 8 bits width with the A variant should be sufficient then.

This might be out of topic, but W is always preferable since this accepts UTF-16 (which can be easily converted from UTF-8) while A accepts local dependent code.

[0xDiddi]

So today I finally got around to testing a bit more.

(I'm using wide variants of the functions)

My go code still returns code 11, still unsure where exactly the error is.

I managed to get it to work however in pure C. Interestingly: at first I got result code 11 here as well.
After switching form sizeof(LPWAVEOUTCAPSW) to sizeof(WAVEOUTCAPSW) as the third parameter it worked flawlessly. This makes sense, as I want to have the size of the struct and not the pointer.

That leaves me with even more questions as before, as now (as far as I can tell) my non-working go code is the exact equivalent of well-working C code.

Here is a gist with my current non-working go code and the working c code.

[0xDiddi]

var caps *waveoutcaps

I was apparently thinking the struct would initialize itself. Which of course it wasn't, and so it failed.

With that out of the way, I should have a working prototype for device selection on windows shortly.

[jessemillar]

@0xDiddi Any progress on your prototype?

[0xDiddi]

University got pretty busy for me last year and I forgot about this. I'll have a look on what the exact status is probably within the week or next weekend.

I think I got at least name-based device selection for playback working, not sure how far I was in presenting a list of the available devices.

[0xDiddi]

It seems like I messed up here somewhat. I reset my pc a few months ago, and while I backed up my own go projects, I ignored all "dependencies", thinking I could simply pull them again, not thinking about this fork. I also didn't have anything committed yet since it was only half-baked, so no hope there either.

I also don't think I will be able to put a lot of time, if any, towards this for another month or two, but I'll be happy to help with questions if anyone else wants to tackle it in the meantime.

[jessemillar]

@0xDiddi Ah. Sad to hear but completely understandable. Thanks for checking!