Outputting to wrong device

[GoogleCodeExporter]

What steps will reproduce the problem?
1.Launch SqueezeLite and instruct it to output to a specific device by name.
2.Turn off TV which disables the HDMI output but also reorders all the device 
indexes. Note that the device I outputted to in step 1 is not the HDMI output
3.Play some music through the SqueezeLite instance that was started in Step 1.

What is the expected output?
Hear sound from the output specified in Step 1.

What do you see instead?
Sound is coming out of the wrong device.

What version of the product are you using? On what operating system?
1.6.3

Please provide any additional information below.
I have a Windows 8 machine that I have two UBS cards in, and HDMI output to a 
surround receiver and an onboard card with a few analog outputs. I have several 
instances of SqueezeLite running and directed at several outputs which go to 
different zones around the house. I have been having problems with the output 
not going where I would expect it. The fix is to restart that instance of 
SqueezeLite. I finally figured out what was going on. If do a -l to list the 
output devices while the TV is on and the HDMI output is alive I get a specific 
list of device indexes. If I then turn the TV off and the HDMI output disables 
I see a whole new list of indexes and they are shuffled all over.

It looks like the output device index looked up by name when first starting 
SqueezeLite and after that it always outputs to that index even if that index 
is no longer correct. Would it be possible to do this lookup every time a new 
stream is started to ensure that it's going to the correct index every time?

Original issue reported on code.google.com by NoelHibb...@gmail.com on 13 Jul 2014 at 11:49

[GoogleCodeExporter]

There's a check on the device id everytime the device is opened/closed which 
should occur if you disable/renable output or if sample rate changes.  It does 
not occur on new tracks at the same sample rate to avoid clicks between tracks.

Suggest enabling -s output=debug and seeing when the device id is checked.

Original comment by trio...@btinternet.com on 13 Jul 2014 at 12:24

[GoogleCodeExporter]

I finally had a chance to turn on debug output and get a better idea of what 
was going on. It's doing exactly what I suspected. It is only looking up the 
device index when the process first launches. If I look at the debug output it 
shows a line like this when I turn the SqueezeLite player off then back on:
[14:32:02.291] _pa_open:260 opened device 5 - Bathroom (USB Sound Device      
at 44100 latency 180 ms

When my TV is turned off the HDMI output is disabled so an index of 5 is 
correct. I will then turn my TV on which should push the index to 6 but even 
after turning my TV on and then power cycling the SqueezeLite player it still 
shows that it wants to send to index 5. But, if I kill the SqueezeLite task and 
then relaunch it while the TV is on it picks up the correct index of 6:
[14:32:20.313] _pa_open:260 opened device 6 - Bathroom (USB Sound Device      
at 44100 latency 180 ms

You're saying there is a check on the device id everytime the device is 
opened/closed but this doesn't seem to be true. It does put in a log entry as 
if it is doing a check, but it isn't really updating to the new index. Maybe 
this is a simple fix, I don't know. Thanks for your very fast response and 
sorry for my very slow response.

Original comment by NoelHibb...@gmail.com on 29 Jul 2014 at 6:40

[GoogleCodeExporter]

Okay I am looking through the source and it does look like it is looking up the 
current device id when it calls pa_open. So I'm thinking this is some sort of 
bug in the portaudio libs?

Original comment by NoelHibb...@gmail.com on 29 Jul 2014 at 7:38

[GoogleCodeExporter]

I think elsewhere in the code I close and then reopen portaudio for this reason 
- can you get it to trigger the case when portaudio sees the device disapear 
and therefore needs to probe for it?  [this may only happen if you delete the 
highest device id from what you are saying?]  It does seem a port audio issue 
thought.

Original comment by trio...@btinternet.com on 30 Jul 2014 at 6:43