Trying to understand audio/video pipes concept (have problem with Marantz A/V

[bulek]

Hi,

I'm trying to clear out behaviour of concpet of audio and video pipes. They are quite useful, but I'm banging my head against a problem, where I'm trynig to write multi zone support for Marantz sr5600 audio receiver (it has 2 output zones if configured in multiroom mode)...

In other related thread on making proper template, Aaron suggested Yamaha receiver GSD that is quite similar. I'm following that example, but can't get it work in that part, where GSD code is trying to determine from which zone command is coming (this is crucial, cause Marantz has different serial commands for main or second output zone - so parent has to distinguish between same commands but coming from different audio zones).

Yamaha template attacks this problem with declaring second embedded child device being generic audio zone - you just put it into that room where you have secondary speakers. Then I did pipe connection to that audio device from MD in that room. Then I also connected that embedded audio zone device to CD input of receiver (that's where the physical line out from MD goes into Receiver).

Now when I start play on that secondary MD, I get this in DCERouter's log :

08      03/20/08 11:07:52.187           Received Message from 41 (Windows XP PC/tablet (Horiz) / Living Room) to 10 (Media Plug-in / ), type 1 id 43 Command:MH Play Media, retry none, parameters: <0x9e4fcb90>
08      03/20/08 11:07:52.187             Parameter 2(PK_Device): 0 <0x9e4fcb90>
08      03/20/08 11:07:52.187             Parameter 13(Filename): !F32794 <0x9e4fcb90>
08      03/20/08 11:07:52.187             Parameter 29(PK_MediaType): 0 <0x9e4fcb90>
08      03/20/08 11:07:52.188             Parameter 44(PK_DeviceTemplate): 0 <0x9e4fcb90>
08      03/20/08 11:07:52.188             Parameter 45(PK_EntertainArea): 9 <0x9e4fcb90>
08      03/20/08 11:07:52.188             Parameter 116(Resume): 0 <0x9e4fcb90>
08      03/20/08 11:07:52.188             Parameter 117(Repeat): 0 <0x9e4fcb90>
08      03/20/08 11:07:52.189           Received Message from 41 (Windows XP PC/tablet (Horiz) / Living Room) to 6 (Datagrid Plug-in / ), type 1 id 35 Command:Populate Datagrid, retry none, parameters: <0x56ee6b90>
08      03/20/08 11:07:52.189             Parameter 4(PK_Variable): 0 <0x56ee6b90>
08      03/20/08 11:07:52.189             Parameter 5(Value To Assign):  <0x56ee6b90>
08      03/20/08 11:07:52.189             Parameter 10(ID): 37 <0x56ee6b90>
08      03/20/08 11:07:52.189             Parameter 15(DataGrid ID): MediaFile_41 <0x56ee6b90>
08      03/20/08 11:07:52.189             Parameter 38(PK_DataGrid): 63 <0x56ee6b90>
08      03/20/08 11:07:52.189             Parameter 39(Options): 4||||1,2|0|13|0 | 2 | 813 <0x56ee6b90>
08      03/20/08 11:07:52.189             Parameter 40(IsSuccessful): 1 <0x56ee6b90>
08      03/20/08 11:07:52.189             Parameter 44(PK_DeviceTemplate): 0 <0x56ee6b90>
08      03/20/08 11:07:52.189             Parameter 60(Width): 1 <0x56ee6b90>
08      03/20/08 11:07:52.189             Parameter 61(Height): 8 <0x56ee6b90>
07      03/20/08 11:07:52.192           Event #21 has no handlers <0xa3e24b90>
07      03/20/08 11:07:52.192           Received Message from 10 (Media Plug-in / ) to -1001 (unknown / ), type 2 id 21 Event:Listening to Media, retry none, parameters: <0xa3e24b90>
07      03/20/08 11:07:52.192             Parameter 27(PK_Room): 7 <0xa3e24b90>
08      03/20/08 11:07:52.196           Received Message from 10 (Media Plug-in / ) to 32 (Kids-Audio / Kids), type 1 id 192 Command:On, retry none, parameters: <0xa3e24b90>
08      03/20/08 11:07:52.196             Parameter 97(PK_Pipe): 1 <0xa3e24b90>
08      03/20/08 11:07:52.196             Parameter 98(PK_Device_Pipes):  <0xa3e24b90>
08      03/20/08 11:07:52.196           Received Message from 10 (Media Plug-in / ) to 219 (Kids - Amplifier (Multiroom) / Kids), type 1 id 192 Command:On, retry none, parameters: <0xb6c34b90>
08      03/20/08 11:07:52.196             Parameter 97(PK_Pipe): 1 <0xb6c34b90>
08      03/20/08 11:07:52.196             Parameter 98(PK_Device_Pipes):  <0xb6c34b90>
08      03/20/08 11:07:52.197           Received Message from 10 (Media Plug-in / ) to 216 (Main Audio - Marantz SR5600 / Living Room), type 1 id 192 Command:On, retry none, parameters: <0xb6c34b90>
08      03/20/08 11:07:52.197             Parameter 97(PK_Pipe): 1 <0xb6c34b90>
08      03/20/08 11:07:52.197             Parameter 98(PK_Device_Pipes):  <0xb6c34b90>
08      03/20/08 11:07:52.197           Received Message from 10 (Media Plug-in / ) to 216 (Main Audio - Marantz SR5600 / Living Room), type 1 id 91 Command:Input Select, retry none, parameters: <0xb6c34b90>
08      03/20/08 11:07:52.197             Parameter 71(PK_Command_Input(CD)): 162 <0xb6c34b90>
08      03/20/08 11:07:52.198           Received Message from 10 (Media Plug-in / ) to 34 (OnScreen Orbiter / Kids), type 1 id 192 Command:On, retry none, parameters: <0xa3e24b90>
08      03/20/08 11:07:52.198             Parameter 97(PK_Pipe): 1 <0xa3e24b90>
08      03/20/08 11:07:52.198             Parameter 98(PK_Device_Pipes):  <0xa3e24b90>
08      03/20/08 11:07:52.198           Received Message from 10 (Media Plug-in / ) to 37 (Xine Player / Kids), type 1 id 192 Command:On, retry none, parameters: <0xa3e24b90>
08      03/20/08 11:07:52.198             Parameter 97(PK_Pipe): 1 <0xa3e24b90>
08      03/20/08 11:07:52.198             Parameter 98(PK_Device_Pipes):  <0xa3e24b90>
08      03/20/08 11:07:52.199           Received Message from 10 (Media Plug-in / ) to 34 (OnScreen Orbiter / Kids), type 1 id 242 Command:Set Now Playing, retry none, parameters: <0xa3e24b90>
08      03/20/08 11:07:52.199             Parameter 3(PK_DesignObj): 54,4962,47,244,224,230 <0xa3e24b90>
08      03/20/08 11:07:52.199             Parameter 5(Value To Assign): ABBA
08      03/20/08 11:07:52.199             Parameter 9(Text): Dancing Queen <0xa3e24b90>
08      03/20/08 11:07:52.199             Parameter 29(PK_MediaType): 4 <0xa3e24b90>
08      03/20/08 11:07:52.199             Parameter 41(StreamID): 1001 <0xa3e24b90>
08      03/20/08 11:07:52.199             Parameter 48(Value): 0 <0xa3e24b90>
08      03/20/08 11:07:52.199             Parameter 50(Name): pluto-xine-playback-window.pluto-xine-playback-window <0xa3e24b90>
08      03/20/08 11:07:52.199             Parameter 103(List PK Device): 37,37,216,,1,0,0 <0xa3e24b90>
08      03/20/08 11:07:52.199             Parameter 120(Retransmit): 0 <0xa3e24b90>

PArticularly important are those :

08      03/20/08 11:07:52.196           Received Message from 10 (Media Plug-in / ) to 219 (Kids - Amplifier (Multiroom) / Kids), type 1 id 192 Command:On, retry none, parameters: <0xb6c34b90>
08      03/20/08 11:07:52.196             Parameter 97(PK_Pipe): 1 <0xb6c34b90>
08      03/20/08 11:07:52.196             Parameter 98(PK_Device_Pipes):  <0xb6c34b90>
08      03/20/08 11:07:52.197           Received Message from 10 (Media Plug-in / ) to 216 (Main Audio - Marantz SR5600 / Living Room), type 1 id 192 Command:On, retry none, parameters: <0xb6c34b90>
08      03/20/08 11:07:52.197             Parameter 97(PK_Pipe): 1 <0xb6c34b90>
08      03/20/08 11:07:52.197             Parameter 98(PK_Device_Pipes):  <0xb6c34b90>
08      03/20/08 11:07:52.197           Received Message from 10 (Media Plug-in / ) to 216 (Main Audio - Marantz SR5600 / Living Room), type 1 id 91 Command:Input Select, retry none, parameters: <0xb6c34b90>
08      03/20/08 11:07:52.197             Parameter 71(PK_Command_Input(CD)): 162 <0xb6c34b90>

and I see some behaviour I'm not sure is consistent with the concept of audio pipe. The whole idea of pipes is about connected devices. So when you start playing something on MD, command On propagates to all connnected devices (amplifiers, TV, and similar). That's probably ok, the problem is that maybe you cannot determin from where did your command come, if media plugin is the sender of all commands to devices on audio pipe... Shouldn't this be changed ?

So my Marantz receiver gets all those commands but not from same source :

20-03-2008  11:07:52   Determine zone for command : 1
20-03-2008  11:07:52   Sending Command: @MSP:2
20-03-2008  11:07:52   Determine zone for command : 0
20-03-2008  11:07:52   Sending Command: @PWR:2
20-03-2008  11:07:52   Got from Marantz: @
20-03-2008  11:07:52   Got from Marantz: @MSP:2
20-03-2008  11:07:54   Determine zone for command : 0
20-03-2008  11:07:54   Sending Command: @SRC:C

First command turns secondary speakers on, second one is power on for receiver (if not already on) and third is input selection. My GSD code (same as that one in Yamaha template) decides from where those commands are coming. And first command On is propagated correctly since Marantz receives it from its child device (that is from embedded audio zone device), but same doesn't happen for other two commands (Media plugin sends them directly to parent Marantz device- and therefore disregards previous destination of commands - I guess commands should go from Media plugin to embedded audio zone device and then it could be parsed correctly with the GSD code in parent device)....

Am I making any sense or am I missing something ? Any opinion would be welcome...

Thanks in advance,

regards,

Bulek.

[bulek]

Hi,

Dealing with another problem related to pipes has popped up some other questions...

I reported this problem :
http://mantis.linuxmce.org/view.php?id=3910

Cause I was getting misterous On command through pipe although media play ended and Off command should be received by receiver.

The problem is that :
1. I made pipe connection from Orbiter(MD) as a whole to receiver (I guess this is waht the whole idea is)
2. after end of media play, Xine player receives Off command, but Orbiter receives On command (probably to redraw it's screen) - but since Orbiter is on pipe, On gets propagated to receiver also.... - that's not ok...

Possible solutions :
a. connect Xine player through pipe to receiver - it solves problem of On command (receiver now gets two Off commands), but volume command don't get to receiver anymore, cause Orbiter receives them in the first place and proceeds to App-server if there is no pipe - so volume stops working...

b. Workaround that On command for Orbiter not to appear on end of media play (make it redraw,refresh or something) and exclude it from sending on pipes. In this case also Off should be sent to MD and then propagated through pipes (if any) and to xine player - does it make more sense ?..

c. Maybe even some third solution, that is the best and consistent with LMCE philosophy and concept of pipes....

Update: There is also another problem that appears when you try to add scenarios for such device. From web-admin forms, you cannot send commands to Audio zone device (that would get intepreted as meant for second audio zone), but you can only send commands to main Marantz device.... Not sure how to tackle this one....
Update2: ok, tried to solve latter one. Have added wanted commands to Zone device and also have added generic inputs, so one can connect audio pipe to Zone device. But it seems that Media plugin disregards this pipe, cause input switch command doesn't reach Zone device, although volume commands get through. I guess this is because Zone is different category than Amps/Receivers. I'm not sure if changing category for Zone device is the right solution, cause it might break something else...

Anyone with more insight ?

Thanks in advance,

regards,

Bulek.

[aaron.b]

The pipes determine how commands get handed along the chain.  Volume commands, for example, follow the audio pipe, so you can send the volume up command to the media director, and it may follow the audio pipe to a receiver, then a/v pre-amp, then an a/v amp.  All those devices along the 'audio pipe' get the command.

99% of the time the output pipe isn't used since most devices can only output one thing at a time.  However in the case of multi-zone receivers, the output pipe is used since it can output two things as once.  Each media stream will cause a certain path along the pipes to be 'active' so the audio/video commands follow the pipes.

[bulek]

Hi,

thanks for response... I agree and understood right the concept. But it seems that there are some certain questions regarding current implementation and performance of pipes.

I have following problems when I try to implement template for two zone receiver using audio pipes. I'd kindly ask if you read my above post where I describe problems I'm getting in implementation... I suspect that there are some inconsistencies in current behaviour of pipes, but could be wrong and I just need to use them differently...

1. I have an MD that I would like to connect as secondary audio source to multizone output:
         - did I understood well that MD as a whole device has to be connected to audio pipe to certain input on receiver ? if no, what device is supposed to be connected to pipe ?
         -  I connect MD to pipe, but when media ends playing, Off command is sent to Xine player under MD, but MD as whole gets command On (maybe to redraw Orbiter) and that command also gets to receiver, that switches On instead of Off.... What is wrong in this occasion ?
         -  it seems that device to be on audio pipe needs to be of somekind of special category or type... Does anyone know what are conditions to be met that device will receive commands ? my question comes from real situation: I've made multizone receiver template with 3 children devices being Output Zones (as suggested in existing template for Yamaha receivers). They are used in embedded fashion, as virtual devices - parent GSD device processes all  commands for them, but it can determine from destination address for which zone commands were sent and he takes coresponding actions on rs232 connection to receiver. But it seems that automatic input switching that Media plugin performs on "normal" receiver devices, doesn't happen on Audio zones, despite the fact they have inputs and that MD is connected to one of them... What to do in such situation...


Thanks in advance,

regards,

Bulek.
 

[aaron.b]

I think you're using this in a different way than it was intended.  The intent was that you can have a few source devices connected to a multi-zone receiver, like, say a CD player, and then you can use those source devices in ANY place where you have an output zone.  The idea was to have each source device go to multiple output zones.  I always tested it using only generic source devices (cable boxes, cd players, etc.) not with a media director, because I media director was always put in a single entertainment area.

Now it sounds like what you're doing is you want 2 media directors connected to the same multi-zone receiver, where 1 md goes to, say the living room (zone 1), and the other md goes to say, the bedroom (zone 2). 

I'm not sure how to do this because I the multi-zone receiver I have, a Yamaha, doesn't work like this.  You can have multiple md's connected to multiple inputs, of course, but any md can go to any output.  In other words, if md 1 is on input 'video 1', and md 2 is on input 'video 2', then you can have zone 1 play video 1, or zone 1 can play video 2, or zone 2 can play video 1, etc.  At least with the Yamaha implementation of multi-zone the concept of having one source that is for zone 1 and another source for zone 2 doesn't exist.  Any source goes to any zone.  That's why I implemented the multi-zone the way I did where the purpose of the multiple output zones is to share input source devices.

The database schema and framework could easily handle both types of scenarios without any changes, but it would probably require a change in the media plugin code that handles a/v pipes to be aware of both types of usage.

[bulek]

First thanks for response... my comments below...

I think you're using this in a different way than it was intended.  The intent was that you can have a few source devices connected to a multi-zone receiver, like, say a CD player, and then you can use those source devices in ANY place where you have an output zone.  The idea was to have each source device go to multiple output zones.  I always tested it using only generic source devices (cable boxes, cd players, etc.) not with a media director, because I media director was always put in a single entertainment area.

hmm, I must admit I never thought of using pipes for anything else than connecting Xine players as sources for multizone audio outputs. Of course, if we get architecture right, then no behavioral difference should exist between HW audio sources (like CDs, DVD players, Cable boxes, Squeezobxes) and SW players (like Xine, Mplayer...). But I guess we're not at that point yet.... My idea of using two Xine players as source for two-zone house audio with Marantz amplifier seems to fit ok. Both zones can listen from same source (both set at same source) or they can listen to different sources. No big difference in such usage scenario...

Now it sounds like what you're doing is you want 2 media directors connected to the same multi-zone receiver, where 1 md goes to, say the living room (zone 1), and the other md goes to say, the bedroom (zone 2). 

I'm not sure how to do this because I the multi-zone receiver I have, a Yamaha, doesn't work like this.  You can have multiple md's connected to multiple inputs, of course, but any md can go to any output.  In other words, if md 1 is on input 'video 1', and md 2 is on input 'video 2', then you can have zone 1 play video 1, or zone 1 can play video 2, or zone 2 can play video 1, etc.  At least with the Yamaha implementation of multi-zone the concept of having one source that is for zone 1 and another source for zone 2 doesn't exist.  Any source goes to any zone.  That's why I implemented the multi-zone the way I did where the purpose of the multiple output zones is to share input source devices.

Well you could imagine as MDs being always connected to its own zone, but also they can "sync" in easy way with selecting same inputs for both output amplified zones....

The database schema and framework could easily handle both types of scenarios without any changes, but it would probably require a change in the media plugin code that handles a/v pipes to be aware of both types of usage.

Hmm that will be a tough one (at least for me)... But for a start: if we say that we would want to add MD among devices that can be shared or connected through pipes - what device exactly would be the choice for putting it into audio pipe connection - pros and cons of few options :

- MD as a whole :   pros: - it will propagate volume and basic play commands
                           cons: - it will send commands that are meant for Orbiter and cause wrong behaviour on receiving device - on end of media play, Orbiter gets On command and this will propagate to piped device, although it should receiver Off...

- Xine player :        pros: - proper Off being send to pipe after play end...
                           cons: - xine doesn't receive volume commands (App_Server is handling it if I remembered right), so you cannot control volume of amplifier instead....

Any opinions ?

Regards,

Bulek.