Print

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

[6233638]

My new DLNA speaker turned up today - a Pioneer XW-SMA3.
 

• Can't seek during playback.
• Can't pause playback unless MC is converting the audio.
• Playback commands sent from the device (prev/next, play/pause) do nothing.
• When set to "specified output only when necessary" Media Center tries to send it audio formats that it doesn't support, and just sits there waiting. Since it's going over WiFi, I would prefer to stream native FLACs where possible, rather than converting everything to WAV.
• Linked playback is several seconds out of sync
• Sync adjustment immediately resets to zero when I try to make a change
• If I stop playback in the middle of a song, and then play something else, the audio buffer is not flushed so you hear a couple of seconds from the previous track before the new album plays.

Is there anything I need to change to get this working?
Are these just things which DLNA is incapable of doing? I had exactly the same problems with the Sony SRS-X7 speakers a few months back.
As with the X7, all of these functions work perfectly via Airplay with zero configuration. (though not via MC, since it doesn't support AirPlay)

[astromo]

May not make any difference but to rule out the obvious, did you update with the latest firmware?

http://www.pioneerelectronics.com/PUSA/Home/Wireless-Speakers/A3+XW-SMA3-K?tab=firmware
http://www.pioneerelectronics.com/ephox/StaticFiles/PUSA/Files/SMA1_3_4/SMA1_3_4_Change_History_PUSA.txt

Don't know whether this thing does that automatically but if it doesn't, then it wouldn't hurt to give it a prod.

[6233638]

That was the first thing I did when I got it. Thanks for the suggestion though.

[Vincent Kars]

The problem with DLNA is that it takes two to tango (sometimes even 3 as one day I had a router not bridging the WiFi and Ethernet properly hence my wireless DLNA renderer wouldn’t talk to my wired server)
Although it is heresy, try Win/WMP. Windows media sharing is  DLNA .
If you have the same problems it is the speaker.
If not, it is JRiver

[6233638]

The problem with DLNA is that it takes two to tango (sometimes even 3 as one day I had a router not bridging the WiFi and Ethernet properly hence my wireless DLNA renderer wouldn’t talk to my wired server)
Although it is heresy, try Win/WMP. Windows media sharing is  DLNA .
If you have the same problems it is the speaker.
If not, it is JRiver

Well that was difficult to set up, since I'm not used to WMP at all.
When playing from WMP I can pause and seek during playback without any problems.
Playback commands sent from the speaker are still being ignored.
 
It would be nice if someone on the Media Center team could comment on whether DLNA even supports a lot of these features, and which are implemented in Media Center.
 

The AirPlay side of it just worked as soon as it was connected to the network. I didn't have to configure a server, seeking works during playback, playback commands sent from the speaker work. (though not with Media Center until they add support)

[JimH]

Well that was difficult to set up, since I'm not used to WMP at all.
When playing from WMP I can pause and seek during playback without any problems.
Playback commands sent from the speaker are still being ignored.
 
It would be nice if someone on the Media Center team could comment on whether DLNA even supports a lot of these features, and which are implemented in Media Center.
 
The AirPlay side of it just worked as soon as it was connected to the network. I didn't have to configure a server, seeking works during playback, playback commands sent from the speaker work.

[AndrewFG]

When playing from WMP I can pause and seek during playback without any problems.

There is absolutely no reason why Pause should work on one client and not on the other. This is because Pause is an entirely atomic action with no arguments or dependencies.

On the other hand, Seek does have arguments and dependencies as follows..

Firstly, Seek allows two modes -- namely relative to current position vs. absolute position from start of the track, and it also allows two position measures -- namely time and "counter" (think of the position counter on old fashioned tape decks). So it could be that WMP is (say) sending Seek / Relative / Counter whereas MC is sending Seek / Absolute / Time (or whatever), and that your player does not support all four combinations. You would need to run a Wireshark on the two transactions to see how the semantics differ.

Secondly Seek requires the renderer to be able to calculate the Seek destination as a byte offset from the start of the file. To calculate the byte offset it needs two out of these three variables i) the full size of the file (provided in the ContentLength header, ii) the time duration (provided in the SetAVTransportURI metadata), and/or iii) the bit rate (also in the metadata). And perhaps WMP is providing two or more of those attributes whereas MC is providing less than two. TIP: in MC server settings, turn on the "bitrate" setting...

Thirdly there are actually two possible HTTP GET syntax forms for Seek -- namely a byte range offset (which is basic standard HTTP syntax), or a time range offset (which requires specific DLNA extensions to HTTP). As far as I recall, recent versions of MC can handle both syntax forms. What version are you using? TIP: try turning on MC's DLNA and/or DLNA Extra settings...

[6233638]

Thanks for the post Andrew.

Code: (Supported Formats) [Select]

http-get:*:audio/L16;rate=44100;channels=1:DLNA.ORG_PN=LPCM,
http-get:*:audio/L16;rate=44100;channels=2:DLNA.ORG_PN=LPCM,
http-get:*:audio/L16;rate=48000;channels=1:DLNA.ORG_PN=LPCM,
http-get:*:audio/L16;rate=48000;channels=2:DLNA.ORG_PN=LPCM,
http-get:*:audio/mpeg:DLNA.ORG_PN=MP3,
http-get:*:audio/x-ms-wma:DLNA.ORG_PN=WMABASE,
http-get:*:audio/x-ms-wma:DLNA.ORG_PN=WMAFULL,
http-get:*:audio/mp4:DLNA.ORG_PN=AAC_ISO,
http-get:*:audio/3gpp:DLNA.ORG_PN=AAC_ISO,
http-wavetunes:*:audio/x-ms-wma:*,
http-get:*:audio/wav:*,
http-get:*:audio/x-wav:*,
http-get:*:audio/flac:*,
http-get:*:audio/x-flac:*,
http-get:*:audio/mp4:DLNA.ORG_PN=AAC_ISO_320,
http-get:*:audio/3gpp:DLNA.ORG_PN=AAC_ISO_320,
http-get:*:audio/vnd.dlna.adts:DLNA.ORG_PN=AAC_ADTS_320
It seems that if I send it "PCM L16 No Header" it won't pause, but sending it "PCM 16-bit" will.

Enabling/disabling DLNA/DLNA Extra, the bitrate, or most of the other options doesn't seem to help at all with seeking.
 
 
I'm using the latest Media Center 19.0.163, and Pioneer claims the device is DLNA 1.5 certified.
Any idea if DLNA supports things like prev/next track from the receiver rather than the server?

[AndrewFG]

It seems that if I send it "PCM L16 No Header" it won't pause, but sending it "PCM 16-bit" will.

Enabling/disabling DLNA/DLNA Extra, the bitrate, or most of the other options doesn't seem to help at all with seeking.
 
I'm using the latest Media Center 19.0.163, and Pioneer claims the device is DLNA 1.5 certified.
Any idea if DLNA supports things like prev/next track from the receiver rather than the server?

Regarding your first point: (just a thought) with PCM no header the track length is and can only be provided in the HTTP ContentLength header, whereas with PCM (basically WAV) there is additionally a RIFF header that provides the same content length by a second means. So maybe the renderer is a bit buggy in that it can read the RIFF but it can't read the HTTP ContentLength (or something like that)..

Regarding your second question: Play, Stop, Prev, Next, and Seek are all mandatory methods in basic UPnP. So even if the player has additional DLNA capability layered on top of UPnP, it shouldn't have any effect on those basic methods.

EDIT: reading your post again, I realised that your second question related to seeking initiated on the player. Actually this is not part of (does not need to be part of) UPnP since that can be done via normal HTTP GET commands from the player. This therefore reinforces my suspicion (first point above) that the player may be a bit buggy..

PS if PCM (wav) works for you then stick to that; the audio quality is identical to L16..

[6233638]

Regarding your first point: (just a thought) with PCM no header the track length is and can only be provided in the HTTP ContentLength header, whereas with PCM (basically WAV) there is additionally a RIFF header that provides the same content length by a second means. So maybe the renderer is a bit buggy in that it can read the RIFF but it can't read the HTTP ContentLength (or something like that).
[…]
PS if PCM (wav) works for you then stick to that; the audio quality is identical to L16..

Yes, I'm happy to use PCM 16-bit (I assume that with only L16 being specified, while it accepts a 24-bit input, it just ignores the rest - I wonder if there is a test for that?) I just thought I'd mention what seemed to be causing the problem.

Regarding your second question: Play, Stop, Prev, Next, and Seek are all mandatory methods in basic UPnP. So even if the player has additional DLNA capability layered on top of UPnP, it shouldn't have any effect on those basic methods.

EDIT: reading your post again, I realised that your second question related to seeking initiated on the player. Actually this is not part of (does not need to be part of) UPnP since that can be done via normal HTTP GET commands from the player. This therefore reinforces my suspicion (first point above) that the player may be a bit buggy..

To be clear, the speaker comes with a remote that has play/pause and prev/next buttons.
These work with AirPlay, but don't seem to do anything via DLNA.

I think I just answered my own question about whether DLNA can support these functions, as I just checked my Sony TVs and they - though when I stop playback on them, Media Center just thinks the connection has dropped and pushes the next track to them - playback has to be stopped via the server.
 
So does this mean that the implementation is broken in the Pioneer speaker (if it's even sending those commands via DLNA?) or is it possible that there are multiple ways to issue those commands, and Media Center is only responding to one type?
 
 
As for seeking, there are no controls for that on the device, I was using Media Center (and JRemote) for control when trying that.
I can't seek when pushing audio to the Sony TVs either.

[AndrewFG]

^
Concerning 24bit sources: MC is transcoding to 16bit. Actually I don't know if it just chops off the LSB; it might be rounding the integer up or down; or possibly even dithering. Someone else will have to answer that for you.

Concerning UPnp push combined with local play, pause actions: As a general rule you should expect this not to work, since you have two conflicting controllers trying to manage one playing session. The local play, pause actions will cause the Http Get to be stalled, restarted and possibly reinitiated with a seek offset, and you should expect the server to be confused by that. If you found a combination of server and player that DOES work in such a hybrid operation mode, then be happy because it is probably more by luck than by design..

[6233638]

Concerning 24bit sources: MC is transcoding to 16bit. Actually I don't know if it just chops off the LSB; it might be rounding the integer up or down; or possibly even dithering. Someone else will have to answer that for you.

Sorry, I meant that the speaker will accept a 24-bit PCM signal, but I was wondering how to test if it's actually operating at 24-bit or treating it as 16-bit.

[AndrewFG]

Sorry, I meant that the speaker will accept a 24-bit PCM signal, but I was wondering how to test if it's actually operating at 24-bit or treating it as 16-bit.

Erm. How much did it cost? 

[6233638]

Well it turned out that it's not doing gapless playback either (funny how it doesn't matter at all until you play certain albums) and since I can't get the playback controls to work, I'm just going to get a refund instead of a replacement due to the WiFi issues my particular speaker has.
 
While I may not have paid that much, this was originally a $429 device from a big-name manufacturer.
 
It just further reinforces my opinion that DLNA as a "standard" is terrible, since even certified devices don't work correctly - either that or it's Media Center's DLNA implementation at fault.
 
 
It's really discouraging when iTunes has perfect multi-room playback on $99 hardware, yet DLNA in Media Center at any price doesn't work properly.
 
I have to assume that the JRiver team either doesn't use networked audio much, or has never actually tried competing solutions to claim that DLNA is even an acceptable standard, let alone comparable to solutions like AirPlay.

[Hendrik]

It might be different if Apple would officially endorse third parties developing AirPlay senders and provide official documentation, but the simple fact that they don't should make any reasons for a software vendors reluctance quite obvious. DLNA is all we have to work with staying clear of the unclear waters of reverse engineered proprietary tech (even if it remains functional in the future, you may be open to litigation)

Maybe you should lobby Apple to open it up instead.

As long as this doesn't change, chances are slim at best.

[6233638]

[moved from request thread by JimH]

Requesting AirPlay support again, since DLNA has a much more limited feature-set and most of it doesn't actually work.
Trying DLNA devices again has just been a waste of time and money.
 
I don't believe that the JRiver team actually uses networked audio on consumer devices (rather than Media Center to Media Center playback) or has tried competing products, since I don't believe they would be recommending DLNA at all if that were the case.

[6233638]

It might be different if Apple would officially endorse third parties developing AirPlay senders and provide official documentation, but the simple fact that they don't should make any reasons for a software vendors reluctance quite obvious. DLNA is all we have to work with staying clear of the unclear waters of reverse engineered proprietary tech (even if it remains functional in the future, you may be open to litigation)

Maybe you should lobby Apple to open it up instead.

As long as this doesn't change, chances are slim at best.

That doesn't seem to have prevented support for DVD/Blu-ray, DTS-HD, iPods etc.
 
Rogue Amoeba has been selling a product based on reverse-engineered AirPlay support for years - and Apple is very aware of it, since they asked them to remove AirPlay receiver support from their iOS app (asked, not litigated against) but have said nothing about their PC/Mac applications.

[Hendrik]

That doesn't seem to have prevented support for DVD/Blu-ray, DTS-HD, iPods etc.

iPod is long before my time, but according to Jim something did happen there to make a lot of work useless later on.
All the others you named are practically free features from JRiver's point of view, ie. no hundreds or thousands of hours effort, so barely any risk.

[6233638]

iPod is long before my time, but according to Jim something did happen there to make a lot of work useless later on.

As I understood it, they switched from making iPods to iOS devices.
I guess Jim thought their implementation would have worked forever but it looked like they got 6+ years out of it before being "obsolete". (Apple still sell iPod classics...)

All the others you named are practically free features from JRiver's point of view, ie. no hundreds or thousands of hours effort, so barely any risk.

It's already open-sourced and reverse-engineered.
I mean, obviously it'll still require work, but it's not like it would have to be developed from scratch as the iPod support seems to have been.
 
If they're looking to expand their market by adding Pono support, supporting the wireless speakers/receivers that most people actually use would help.
 
It's prevented me from being able to buy a wireless speaker (since DLNA ones are all "bad implementations" apparently) and doesn't work with my existing wireless zones. (all AirPlay hardware)
It's also been the #1 thing preventing other people I have recommended Media Center to, from buying the program.

[Hendrik]

The AirPlay protocol is quite complex honestly, at least from a first glance. It doesn't use simple HTTP streaming like DLNA, but uses RTSP/RTP to send data, which we don't have yet for anything else.
Just from a implementation standpoint, its not a "free feature" to any degree, even if we don't have to figure out how it works anymore.

[jmone]

I posed this q to Andrew in another thread... surely there is a way of getting better sync using DLNA than what we currently have.  My experience is that the devices end up on different tracks very quickly.  If we could just have each device start playback of each new track together in a playlist then it would only be device clock drift on a per track basis and that should not be too much.

[apgood]

DTS Play-Fi seems to be starting gain traction with hardware manufacturers and has audio syncing across devices built in. Maybe it might be a viable option to DLNA and Airplay since I assume it can be licensed....

[JimH]

As I understood it, they switched from making iPods to iOS devices.
I guess Jim thought their implementation would have worked forever but it looked like they got 6+ years out of it before being "obsolete". (Apple still sell iPod classics...)

It was never obsolete.  Apple locked developers out by encrypting their database.  Several tried to get around that, but Apple just changed their method each time.

Apple isn't a nice company in spite of what many people think. 

They will manage without JRiver's support.

[JimH]

I don't believe that the JRiver team actually uses networked audio on consumer devices (rather than Media Center to Media Center playback) ...

You would be wrong.  We have and use many devices.

Your persistent complaints about DLNA and about JRiver's business strategy aren't helpful.  Like all things in computing, you have to find what works for you, and make compromises where you need to.  Or build your own.

[JimH]

I'll leave this thread open for an hour or two to allow replies, but then I'll lock it.

[AndrewFG]

FWIW I think UPnP /DLNA beats AirPlay hands down. AirPlay does not support hi-res audio, and it is completely useless for decent quality video streaming.

[6233638]

You would be wrong.  We have and use many devices.
Your persistent complaints about DLNA and about JRiver's business strategy isn't helpful.  Like all things in computing, you have to find what works for you, and make compromises where you need to.  Or build your own.

Well I'm posting about it again because I gave DLNA another try after you said that AirPlay would not be supported, and that DLNA should work just as well as AirPlay. It's costing me time and money to do this.
 
If it actually worked, I wouldn't have anything to complain about.

FWIW I think UPnP /DLNA beats AirPlay hands down. AirPlay does not support hi-res audio, and it is completely useless for decent quality video streaming.

It certainly beats it on paper, but high res only matters if you're feeding an external DAC or stereo system.
 
I'm more concerned about whether things like gapless, seeking, playback control, and sync works, or whether I can send audio directly to the receivers from mobile devices, than whether or not I can send it high res audio.
I use wired connections for that sort of thing.