Playing 96KHz/32bits wav file failed!

[storaid]

Hello, Tiki

plz try this sample link:

https://1drv.ms/u/s!AvA1navurakAiKhWJYeW_kQUPN0Jwg?e=QNovbd

{
"creatingLibrary":{"name":"MediaInfoLib","version":"23.10","url":"https://mediaarea.net/MediaInfo"},
"media":{"@ref":"D:\\OneDrive\\Private\\01_チア・チア_やくしまるえつこ.wav","track":[{"@type":"General","AudioCount":"1",
"FileExtension":"wav",
"Format":"Wave",
"Format_Settings":"PcmWaveformat",
"FileSize":"78894853",
"Duration":"102.727",
"OverallBitRate_Mode":"CBR",
"OverallBitRate":"6144040",
"StreamSize":"333",
"Title":"01_????_????????",
"Album":"[Hi-Res]やくしまるえつこ - チア・チア",
"Track":"01_チア・チア_やくしまるえつこ",
"Performer":"やくしまるえつこ",
"Director":"????????",
"File_Created_Date":"2023-11-15 13:42:48.762 UTC",
"File_Created_Date_Local":"2023-11-15 21:42:48.762",
"File_Modified_Date":"2019-10-10 09:38:16.470 UTC",
"File_Modified_Date_Local":"2019-10-10 17:38:16.470",
"OriginalSourceForm_Name":"[Hi-Res]???????? - ????"},{"@type":"Audio","Format":"PCM",
"Format_Profile":"Float",
"CodecID":"3",
"Duration":"102.727",
"BitRate_Mode":"CBR",
"BitRate":"6144000",
"Channels":"2",
<strong>"SamplingRate":"96000"</strong>,
"SamplingCount":"9861815",
<strong>"BitDepth":"32"</strong>,
"StreamSize":"78894520"}]}
}

I got an error message “Unsupported format” from DENON HEOS App

Test devices:
1. Denon: no response
2. iFi Streamer: Successful

[Tiki]

I tried.

It seems that the TuneBrowser handled this file without any problems. Please ask to the device vendor.

[storaid]

Hello, Tiki,

Indeed, I was informed that the Denon device does not support this file format…

However, I’m curious as to why the on-the-fly transcoding does not occur?

Thanks

[Tiki]

However, I’m curious as to why the on-the-fly transcoding does not occur?

The reason is that whether to apply audio/L16 or not is based on the information in MIME.

At the MIME level, Renderer seems supporting wav.

[storaid]

Hello, Tiki

the following is from Denon device:

http-get:*:audio/mpeg:*
http-get:*:audio/vnd.dlna.adts:*
http-get:*:audio/x-ms-wma:*
http-get:*:audio/x-ms-wma:*
http-get:*:audio/L16;rate=48000;channels=2:*
http-get:*:audio/L16;rate=48000;channels=1:*
http-get:*:audio/L16;rate=44100;channels=2:*
http-get:*:audio/L16;rate=44100;channels=1:*
http-get:*:audio/wav:*
http-get:*:audio/mp3:*
http-get:*:audio/flac:*
http-get:*:audio/aac:*
http-get:*:audio/m4a:*

[storaid]

Logging:

2023/11/16 21:49:30,359: UL00515: T0f728: UPnP_P: PlayerLogToUPnP is enabled.
2023/11/16 21:49:30,360: UL00517: T0f728: UPnP_P: Created player object: [UPnP: Denon Home 350]
2023/11/16 21:49:30,363: UL00520: T0f728: UPnP_P: Stage: [InitializePlayer]
(omitted because of too long)

Capture from wireshark:

 

[Tiki]

As I said above, renderer is supporting wav. So TuneBrowser is using original wav file.

http-get:*:audio/wav:*

[storaid]

Hello, Tiki

As I said above, renderer is supporting wav. So TuneBrowser is using original wav file.

I see

But this leads to the problem I mentioned where the TuneBrowser player doesn’t perform any action.

Is there any possible way to improve this problem in this case?

Thanks

[Tiki]

The renderer does not return an error. So, the TuneBrowser cannot detect error.

I attached the log you uploaded above.

Attachments:

1. UPnP-Log.log

[storaid]

Hello, Tiki

So, the TuneBrowser cannot detect error.

You mean it is not capable of detecting errors from RST response???

Thanks

[Tiki]

No errors have occurred in UPnP (SOAP and GENA) processing.

I think the RST was generated during the HTTP file transfer, but the TuneBrowser does not determine from this behavior that the renderer is not capable of playing the file.

[storaid]

Hello, Tiki

What actually happens next when the TuneBrowser player receives no errors?

Even if TuneBrowser was unaware of RST happened.

[Tiki]

What actually happens next when the TuneBrowser player receives no errors?

The TuneBrowser’s Media Server (HTTP Server) sends the file. And stops sending when the renderer stops receiving or some error occurs or the connection is closed.

[storaid]

Hello, Tiki

I did take a look at the UPnP log and noticed the following as a part of it.

2023/11/22 18:54:04,016: UL02346: T0a6b8: UPnP_P: [ResolveTune]: URI: [http://10.1.1.156:10960/TuneID/00013389.wav]
2023/11/22 18:54:04,017: UL02348: T0a6b8: UPnP_P: [ResolveTune]: - Mine:Yes Managed:Yes Recorded:Yes Local file: [\\NAS1\music\[Hi-Res]やくしまるえつこ - チア・チア\01_チア・チア_やくしまるえつこ.wav]
2023/11/22 18:54:04,018: UL02350: T01b90: UPnP_P: Proc PlayerNotify: 0003 [Start]
2023/11/22 18:54:04,031: UL02352: T01b90: UPnP_P: Proc PlayerNotify: 0003 [Started]
2023/11/22 18:54:04,119: UL02354: T08fb4: --> EVENT /SR_AVTransport: uuid:73556646-8925-11ee-b641-83d7476a55a3
2023/11/22 18:54:04,119: UL02356: T08fb4: Subscriber: [Event]: Received EVENT: [AVTransport]
2023/11/22 18:54:04,119: UL02358: T08fb4: Subscriber: - [AVTransport]: Device notification: [TransportState ] : [STOPPED]
2023/11/22 18:54:04,119: UL02360: T08fb4: UPnP_P: [Proc:TrState ]<EVT>: PlayerUPnP UPState changed [PLAYING ] to [STOPPED ]
2023/11/22 18:54:04,119: UL02362: T08fb4: UPnP_P: [Proc:TrState ]<EVT>: PlayerUPnP PLStatus changed [PlayStatus::Playing ] to [PlayStatus::Stop ]
2023/11/22 18:54:04,119: UL02364: T08fb4: UPnP_P: [Proc:TrState ]<EVT>: Stop detected.
2023/11/22 18:54:04,119: UL02366: T08fb4: UPnP_P: [Proc:TrState ]<EVT>: Next tune sequence position 0 -> 1.
2023/11/22 18:54:04,119: UL02368: T08fb4: UPnP_P: [Proc:TrState ]<EVT>: Player is UnderControl. Next tune SeqPos:1 found. Continue playback.
2023/11/22 18:54:04,119: UL02370: T08fb4: UPnP_P: [Proc:TrState ]<EVT>: PlayerStatus: Continue
2023/11/22 18:54:04,119: UL02372: T08fb4: UPnP_P: [Proc:TrState ]<EVT>: State : STOPPED

Could these triggered events above have been caused by playback, resulting in the stopping of playback?

Thanks

[Tiki]

It is necessary to consider the possibility that the stop was made by another controller.

[storaid]

Hello, Tiki

Do you mean being able to further fine-tune UPnP’s operations in this case?

Thanks

[Tiki]

?

Could these triggered events above have been caused by playback, resulting in the stopping of playback?

It is necessary to consider the possibility that the stop was made by another controller.

I was taking about triggered events in your log.

 

As I said first, the TuneBrowser is working well for your file. At this time, I think there is no “further fine-tune”.

If you want to adjust by changing the setting:

– TreeItem: Playback settings – External UPnP renderer settings
– Property: External UPnP renderer settings – Use audio/L16

If set this item to “If possible”, your file will play by your renderer as audio/L16. But most other files will also play as audio/L16. Perhaps that is not the result you want.

[storaid]

Hello,

As I said first, the TuneBrowser is working well for your file. At this time, I think there is no “further fine-tune”.

Ok, thanks

[Tiki]

Thank you for your understanding.

[Tiki]

I have added a USE_AUDIO_L16 tag support into the TuneBrowser 5.4.2.

If you set the value of this tag to 1, the TuneBrowser will tell the UPnP Renderer to use audio/L16.

Maybe this behavior will help you.

[storaid]

Hello, Tiki

Thank you for your help.

However, this improvement in functionality does not resolve my issue.

This is because it’s a problem caused by format unsupported.

The issue arises because Denon does not support 32-bit sources; Denon Home only supports PCM format up to 192k/24bit.

I am not sure if TuneBrowser can detect this problem.

I have captured packets with Wireshark and indeed, it returned a large number of RST packets.

Packet dump file(Wireshark):

https://1drv.ms/u/s!AvA1navurakAiKkyzo_EU0ylg74uDQ?e=JO5uJ4

 

Thanks

[Tiki]

Thanks for the confirmation and your time.

I’m sorry it didn’t help.

That’s all of I can do about this matter.

[storaid]

Hello, Tiki

I have a question.

When the receiver cannot process an unsupported file, but the requested file format matches the receiver’s supported MIME, and it’s only the Sample Rate or Bit Depth format that is incompatible, how will TuneBrowser handle this situation further?

Indeed, there are a large number of RST packets being returned.

However, I am not sure whether TuneBrowser can discover this.

[Tiki]

UPnP controler (=TuneBrowser) determines which file to send based on only MIME information.

Before playback, controler sends SetAVTransportURI SOAP command to renderer. This command includes resource info like sample rate. If renderer accepts this command, then controler sends “Play” SOAP command.

On the other hand, UPnP media server (is also TuneBrowser) sends file when http get request is received.

Renderer can return error to controler as response of SOAP command.

These are almost all of the processes.

[storaid]

Hello, Tiki

I have used some UPnP development tools for testing and I think I have identified the clues.

Although the renderer is unable to do successful playback and is returning a large number of RST packets, the problem is that the SOAP call to ‘Play’ does not return any errors, nor are any exceptions thrown.

This apparently leads TuneBrowser to be unaware of the actual status of the renderer.

I believe this could explain why TuneBrowser assumes that the ‘Play’ SOAP operation is proceeding without any anomalies.

 

[Tiki]

I can’t understand from the screenshot, but if an RST is being returned, it will be to the media server.

[Tiki]

Anyway, it is sure that the TuneBrowser cannot detect problem from this control situation.

Can I close this topic ?

[storaid]

Can I close this topic ?

OK, very thanks for your help.

PS: I tested other players, such as Foobar2K and Synology Audion Station, and there is the same problem too.

[Tiki]

Thank you for your understanding and P.S. info.

[投稿者]

投稿