Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Bccc1]

Is it possible to add a custom toggle/button to a skin which changes a zoneswitch rule or sets a variable which then can be used in a zoneswitch rule?

Background: I have two output targets, my speakers and my headphones and I want a way to easily switch the loopback-target. At the moment I have a simple [Filename]=[live:////ipc" with the speakers-zone as target.

[Castius]

I have the same setup. I'd like to improve my workflow as well.

[mwillems]

I think there's an easy way to do this, here's my advice: create a separate loopback zone for headphones so you'd have four zones:

1. Speaker loopback zone
2. Speaker regular zone
3. Headphone loopback zone
4. Headphone regular zone.

The loopback routing rule in 1) should be the exact same as the rule in 3) (but targeting the appropriate device), and the routing rule in 2) should be the same as 4), etc.

But here's the crucial part: A. make sure that the two speaker zones (1 and 2) stop playback in each other and no other zones and B. make sure that the two headphone zones (3 and 4) stop playback in each other and no other zones.

If two zones have mutual stop playback rules they form a "closed ecosystem" and their rules don't get checked when playback is started in a zone outside of that mutual stop playback relationship.  Once you get this setup, to switch between headphone and speaker playback all you would have to do is select one of the headphone or speaker zones and the loopback should then go to the headphone or speaker zone as appropriate.  

It should be as simple as that;  I can't test right now as I'm in front of a linux box, but I'll test next time i'm in windows, and if you beat me to it EDIT: just tested in windows and it worked perfectly.  Let me know if you have any trouble with it.

[Bccc1]

Thanks for the help 

I already had those zones because I want to simultaneously play a song and have sound from a game.
To not mess that up, I created two dummy zones, so I have:
Headphones
Headphones Loopback
Headphones Dummy
Speakers
Speakers Loopback
Speakers Dummy

And the Rules:
JRiver Driver Speakers
Rule: [Filename]=[live:////ipc"
Target: Speakers Loopback
Stop: Speakers Dummy

JRiver Driver Headphones
Rule: [Filename]=[live:////ipc"
Target: Headphones Loopback
Stop: Headphones Dummy

If one of the dummyzones is active, loopback goes to the corresponding zone. But if Speakers or Headphones is active, loopback fails to start. I guess because as you said the rules are encapsulated in their ecosystems and not checked. How do I fix this?

Additionally, is there a way to access the zones section without leaving the audio section? If I go to zones and back to audio am at the rootlevel and have to navigate back to where I was, so I'd like a zoneswitch option where I don't have to leave where I am. Thus the idea of a button in the skin.

[mwillems]

And the Rules:
JRiver Driver Speakers
Rule: [Filename]=[live:////ipc"
Target: Speakers Loopback
Stop: Speakers Dummy

JRiver Driver Headphones
Rule: [Filename]=[live:////ipc"
Target: Headphones Loopback
Stop: Headphones Dummy

What purpose do the dummy's serve exactly? In my example 2 and 4 were supposed to be the normal zones you use for playback to headphones and speakers.  

Is it that you don't have a corresponding routing rule to get non-loopback content routed to the right place?  The easiest one is just the reverse of the loopback rule: use the following rule targeting your normal speaker and headphone zones

Code: [Select]

-[Filename]=[live:////ipc"
If you have that rule targeting your normal zones alongside the loopback rules, loopback will go to the loopback zones and anything else will go to the normal zones.  Try it without the dummy zones.

If one of the dummyzones is active, loopback goes to the corresponding zone. But if Speakers or Headphones is active, loopback fails to start. I guess because as you said the rules are encapsulated in their ecosystems and not checked. How do I fix this?

You need to include the regular zones in the mutual stop playbacks; if you use the routing rule I mentioned above and eliminate the dummy zones it will work better.

Additionally, is there a way to access the zones section without leaving the audio section? If I go to zones and back to audio am at the rootlevel and have to navigate back to where I was, so I'd like a zoneswitch option where I don't have to leave where I am. Thus the idea of a button in the skin.

That part I'm not sure about; maybe someone else has an idea?

[Bccc1]

What purpose do the dummy's serve exactly?

The encapsulated ecosystem thing seems to only work if I set the stop playback field. But I do want to simultaneously playback from the WDM Driver and my music library. I thought maybe I could build the system you suggested and have an additional zone for simultaneous playback. The Dummy-zones would be the "trigger zones" and the regular zones would be for normal music playback. But, as I already wrote, that doesn't work. If I think about it, that's not a surprise, but I can't think of a solution. I guess I'd need a way to add the regular zones to the corresponding ecosystems without adding them to the stop-playback-list.

Edit: I misunderstood the stop playback in these zones feature. I thought if something was send by this rule to speakers loopback, then all playback on speakers would be stopped, but this is not the case. The solution you suggested works just fine and my dummy-zones are useless  
What does this stop playback thing actually do? In which cases what is stopped?

Edit2: I just found out that you can set up zoneswitches to specific zones in the remote control options. That's good enough for me.

[mwillems]

Edit: I misunderstood the stop playback in these zones feature. I thought if something was send by this rule to speakers loopback, then all playback on speakers would be stopped, but this is not the case. The solution you suggested works just fine and my dummy-zones are useless  
What does this stop playback thing actually do? In which cases what is stopped?

The stop playback setting does what it says, except for loopback.  I think that was a conscious design decision on the part of the JRiver team to stop the WDM driver from interrupting playback already in progress (i.e. how irritating would it be if system sounds shutdown your music constantly, etc.).  If you have loopback content playing and you try to play some audio in JRiver it should (temporarily at least) stop the loopback feed; it just doesn't work in reverse (loopback won't stop playback in a normal zone).

If you actually wanted mutually exclusive playback, the secret is to use an exclusive access mode in both zones (i.e. single-client ASIO or WASAPI with the exclusive access options checked)