Do you have control of sonos to call line in? I know you can always use the sonos remote to select line in but if roomie could, then you could have better use when using the line in for a TV output.
Sure, just send the command .LINEIN SET to the device. Then send a PLAY command.
Thank you.
THANKS!
I’ve gotten .line set to work wonderfully when the speakers I’m using are connected to the Sonos device for which I’m doing the .Linein set. How do I listen that to that line-in from on a different sonos device? I assumed I would use “.Source” for this, with a parameter of something like “Home Theater: Family Room” (where “Home Theater” is the name I gave to the line-in for the family room. Help please.
Thanks,
Ed
Grouping is accomplished using the Group button at the top of any Sonos Virtual Remote.
Thank you.
I don’t want to group. I want to set the source of a particular sonos Connect:amp to a line-in that is not the line-in on that amp, but rather the line-in on a different Connect.
Thanks,
Ed
Right. That’s called Grouping because you want to group Sonos 1 and Sonos 2 together such that Sonos 2 follows whatever Sonos 1 is doing.
Thank you.
Sorry, what I’m talking about is not grouping, and further in its general form can’t be done with grouping (though as noted a subcase of it can be). Let me give you an example. Suppose I have two Sonos Connect:AMPS, call them A and B, each with something connected to their respective Line-Ins. Sonos allows me to have the Source for A be B:Line-In, and the source for B be A:LIne-In. The reason this is an important distinction is that it means that even if B isn’t putting sound out its speakers (i.e B has no music source selected), I can still use as a source in another room B’s Line-in. Even further, B could playing a COMPLETELY different music source (Rhapsody, etc…) and A can still use B’s line-in as a music source. Hence you can see this is very different from Grouping.
So why do I care. I know you guys are busy so I’m not trying to waste your time. Two reasons:
(1) Though grouping doesn’t really do what I want, as explained below I could probably use it if I could automate it as part of an activity. Is there a way to insert commands as part of an activity that would automatically group two named sonos players without requiring the user to select the players via the UI (that’s what seems to be required using the virtual remote)?
(2) as to what I’m doing: In my house I have a centralized cabinet that has Connect:amps for each room. This is my whole home distribution system. In addition in some rooms (those with TVs and no fancy receiver), I have various devices (STB, Apple TV) plugged directly into the TV. So far so good and roomie works perfectly for controlling all of this. In addition in those rooms I have a Sonos Connect (no amp) whose line-in is connected to the audio output of the TV (and the TV’s internal speakers are disabled), and whose output goes no where. Think of this as a networked audio source device. It let’s me take the audio for the device selected for that TV and put it into my sonos-sphere. I want to be able to select the line-in of the Connect as the source for the Connect:Amp.
To be concrete: I have a Connect:AMP, let’s call it RoomSpeakers, and a Connect, let’s call it RoomAudioSources. What I’d like is a way to set the source for RoomSpeakers to be RoomAudioSources: Line-in.
Now if you’ve followed me this far, you will indeed note that in the end I could do my specific case with grouping, by setting the Source for RoomAudioSources to be its Line-In, and then grouping RoomSpeakers with RoomAudioSources. Though not as elegant, it would work for me as RoomAudioSources doesn’t itself drive any speakers directly so it really doesn’t matter what its source is set to. So as noted in (1) above, I’d be happy with grouping as an answer if I can do it without the user having to do it manually via the virtual remote. That being said, the more elegant answer (per my A, B example above) of being able to set the source of one sonos device to the line-in of another sonos device would be better, as it is fully generalizable.
Thanks,
Ed