UPnP stream or Remote?

[WanFie]

Dear Mr. Tiki,
As you know, I find TuneBrowser the best sounding audio software I have ever used. Better than the well-known, widely used audiophile players.
I do have a problem that occurs occasionally. I have opened a topic about this in the past. The conclusion was that UPnP streaming from my tablet showed problems. After I installed a better WiFi installation and bought a somewhat faster tablet, it was indeed better. But still… sometimes the music still stutters.
I have now installed WiFi analyzer on my tablet and see big differences in data transfer between e.g. JRiver and TuneBrowser. That is 1 Kb/s with JRiver and 750 Kb/s with TuneBrowser. I think that the stream with TuneBrowser runs via the control point. With other Openhome software, this goes directly from the network to the PC. The control point is only used as a remote there. The result is that the stream is much lighter and therefore has less interference.

Is it possible to adjust this in TuneBrowser?

I use BubbleUPnP on a Lenovo Tablet.
TuneBrowser runs on a dedicated self-built streamer based on Windows.
A powerful WiFi access point is three meters from the tablet.

Thanks in advance,

Kind regards,

Hans

(from the Netherlands)

[Tiki]

Hello. Thank you for using TuneBrowser.

The routing of data during UPnP playback depends on controller operation and equipment configuration. For example, in the following simple configuration, TuneBrowser performs local playback without networking.

• TuneBrowser(Media server) -> Controller -> TuneBrowser(OpenHome player)

If you describe the path of the data, maybe I can find out something.

[WanFie]

Thanks for the quick answer.
I think the difference in the distance traveled is different for both systems.
1. Tunebrowser:
Qobuz-> network -> wifi -> tablet -> wifi -> streamer.
2. e.g. JRiver or Openhome player
Qobuz-> network -> streamer. And besides that, the remote control via Wifi and the tablet.

In case 1. all data runs via the tablet (a lot of data over wifi).
In case 2. the data goes directly into the streamer and the tablet is only used as a remote control (little data over Wifi).

Kind regards

[Tiki]

Thank you for your response.

I understood that TuneBrowser is running on “streamer”.

You can see which file(URL) TuneBrowser is playing. Please check following. On the Player View, hover the mouse over the rectangle that appears to the left of the track.

Hope this information helps.

[WanFie]

[WanFie]

192.168.2.206 is the ip number of the controller/tablet.

Thanks

[Tiki]

Thank you.

Then it seems that your controller/tablet is relaying and sending out data. From the TuneBrowser side, I don’t know why your controller/tablet is working that way.

[WanFie]

That the stream is controlled by the tablet, I think is correct.

When I look in JRiver I see exactly the same file name, also starting with the IP address of the tablet.

Yet with JRiver and the same track (192/24) only 1 Kb/s of data passes through, while with TuneBrowser it is 750 Kb/s. So there is a big difference somewhere in the processing of the data from the internet to the streamer.

Kind regards.

[Tiki]

Thanks.

That’s strange… Are you using RAMDecode function ?

If you are using it, please turn it off and see if the behavior changes.

[WanFie]

That was indeed on, but is now off.
However, the data stream remains at approx. 750 Kb/s with TuneBrowser and approx. 2 Kb/s with JR. Now with the album At The Renaisance, by Ben Webster 192/24.
In the streamer I see a data stream of 250 Kb/s. So it does indeed seem that the data stream goes directly from the network to the streamer.

Kind Regards.

[WanFie]

Some additional information.
I had the cache size set to 64 kB. I have now set it to 6400 kB. The wifi pattern now looks completely different. Each time for approx. 8 sec. approx. 1 Kb/s and then again for a short period 2.5 Mb/s (= 2,500 Kb/s). and so on. With JR the data stream remains approx. 1.5 Kb/s during the entire track. Also during the start of the track.

Kind Regards.

[WanFie]

There is a setting in JR that allows other UPnP devices to control JR. It is enabled here. Maybe that makes the difference in data stream?

 

Kind Regards.

[WanFie]

I now sometimes have problems with crashes when switching from one track to another. I found a new setting, a pause operation type. I have now set it to type 1. Maybe it helps?
Furthermore, I now have little problems with interruptions in the music. But the data pattern remains very different.

[WanFie]

unfortunately… no solution. Crashes again. I never had this before. Has anything changed here?

[Tiki]

I’m sorry for my late response.

I can not determine the reason for the traffic behavior. Pause Type 1 is for USB DAC. Unfortunately, there is no relation.

If TuneBrowser crashes, it will detect the dump file at the next startup. If it finds one, follow the instructions in the dialog box and please send it to me.

[WanFie]

Thank you very much for the answer. I really appreciate your efforts.
I play with a USB DAC. namely the Teac UD-701n. With the “Bulk Pet” driver.
Tunebrowser on the Windows streamer sounds much better than the built-in Teac streamer. Read this as a big compliment.
Pause type 1 indeed brought nothing. So it is back to 2. There are so many settings possible that the best setting has many choices. It would therefore be useful if the standard setting were mentioned for each item in the text below.

[WanFie]

Unfortunately, I have had several crashes, but no error log.

They occur, when I choose another track while the previous one is still running. In the past this worked without problems.
I play from Qobuz and use UPnP with control point BubbleUPnP.

Now that Qobuz can also be used in Japan, this solution is suitable to play that music with TuneBrowser. And, with the highest quality!!

[WanFie]

The remarkable thing is that with version 5.6.1 the crashes have also disappeared.
I do notice that after a short interruption of the internet the music is resumed, but that a series of interruptions occurs.
I have built a second steamer for the living room. This one is connected with an internet cable. If I pull out the cable during playing and put it back in after stopping the music, the stuttering starts. Pressing the pause button and starting again solves the problem.
A short signal (Wifi?) interruption is therefore sufficient to start the stuttering.

[Tiki]

Thanks for information that how things are going. It is good to hear that the crashes are gone (although I don’t know why).

I think that the TuneBrowser may be operating inefficiently in some environments, but without reproducing the behavior, it is difficult to make improvements. I will continue to improve the TuneBrowser if there are inefficient parts in its operation.

[WanFie]

We also figured out what was causing the disruptions to my audio friend. Fidelizer Audio! that sets a timer function too short, which may sound better, but makes Windows too unstable for audio playback.

In the meantime, we still listen to music via TuneBrowser. Simply because it sounds considerably better than, for example, JR and Roon.

Tiki, thank you very much for this wonderful program.

[Tiki]

Thank you for the additional report. I am glad to hear that it worked well.

Then, may I now close this topic?

Thank you for loving TuneBrowser !

[WanFie]

Yes, but not before I thank you again for the great support.

Greetings from the Netherlands

[Tiki]

Thank you.

[投稿者]

投稿