Skip to content
This repository has been archived by the owner on Dec 13, 2020. It is now read-only.

Sluggish start of play with SS 5.2.1 #4

Open
elduderino5k opened this issue May 2, 2015 · 12 comments
Open

Sluggish start of play with SS 5.2.1 #4

elduderino5k opened this issue May 2, 2015 · 12 comments

Comments

@elduderino5k
Copy link

After upgrading to Subsonic 5.2.1, I notice that iSub has a hard time starting a track…I hit play on something that is not cached, and it takes often 30-45 seconds for the track to actually start playing consistently (I might get a brief flash of music, but then it’s gone)….almost like now it’s trying to fill up a buffer that it never had to before. Again, never an issue under 4.7

@elduderino5k
Copy link
Author

This issue seems worse over client wifi networks, even great quality ones, and not so bad over mobile cellular networks, which is odd.

@einsteinx2
Copy link
Owner

I'm not seeing this issue in my setup, but I'll keep this open for now to investigate further.

@justindhill
Copy link
Collaborator

These symptoms sound like the result of less-than-adequate upstream capacity on your Subsonic server. Over mobile networks, iSub will request a lower-bitrate file from Subsonic, which will transcode it on the fly, resulting in you getting more of the song faster.

@einsteinx2
Copy link
Owner

Good point Justin, that sounds like a probable explanation.
On Wed, Feb 3, 2016 at 9:36 AM Justin Hill notifications@github.com wrote:

These symptoms sound like the result of less-than-adequate upstream
capacity on your Subsonic server. Over mobile networks, iSub will request a
lower-bitrate file from Subsonic, which will transcode it on the fly,
resulting in you getting more of the song faster.


Reply to this email directly or view it on GitHub
#4 (comment).

@elduderino5k
Copy link
Author

Ben, you can close that one…it was my fault completely…i’m working on getting you an account on my server for DSD file testing and whatever else for high rez audio. Thanks!

On Feb 3, 2016, at 12:23 PM, Ben Baron notifications@github.com wrote:

I'm not seeing this issue in my setup, but I'll keep this open for now to investigate further.


Reply to this email directly or view it on GitHub.

@einsteinx2
Copy link
Owner

Great thanks!

@elduderino5k
Copy link
Author

Guys, I have 80MB down and 25MB upstream on a Business class connection to my Subsonic server. The issue is not bandwidth up or down in my case - I will tell you that I stream 1080p video with Air Video HD from here as well and it works marvelously and looks picture perfect beautiful on a 70 inch screen, and now even directly to the 4th Gen AppleTV natively with the built in Air Video app! But I digress - but your response concerns me Justin a great deal - are you saying that iSub the client is deciding on its own whether to stream at a lower bit rate from my server? Assume that I am on an Unlimited data plan with my mobile carrier, and that I’m in a great LTE-5 bars connection area with a great GSM provider, are you saying that still in that case (or in any case) that iSub is making a determination to stream a lower bit rate file? This flies in the face of my wishes, my understanding, and more importantly the settings under Settings, wherein the user chooses his bit rate choices for Wifi and Cell connections…if I’ve set it to “No limit”, then I want the exact bit for bit streaming of the raw file (no transcoding in my case) to the iSub client. Assume a normal FLAC file on the Subsonic server, and again, assume that transcoding is totally disabled for FLAC, such that a native FLAC stream should be coming to the iSub client…why is iSub trying to down-sample that file? I should be able to get a bit for bit stream if that’s what I’ve chosen to do, no? What am I missing? This will become even more important as we try to stream DSF files from DSD content, which is even heavier than FLAC or even high rez FLAC that I’m streaming today.

Please illuminate my brain, it definitely needs it :-)

On Feb 3, 2016, at 12:36 PM, Justin Hill notifications@github.com wrote:

These symptoms sound like the result of less-than-adequate upstream capacity on your Subsonic server. Over mobile networks, iSub will request a lower-bitrate file from Subsonic, which will transcode it on the fly, resulting in you getting more of the song faster.


Reply to this email directly or view it on GitHub.

@justindhill
Copy link
Collaborator

You absolutely can disable transcoding in settings, and iSub will play whatever comes back from Subsonic, but you can imagine that less savvy users would be very pissed off if iSub caused them to go over their monthly bandwidth allotments. I was merely hypothesizing a cause based on your description of the symptoms. Going off of Ben's agreement with my assessment, I don't think this was an unreasonable first stab lol.

@elduderino5k
Copy link
Author

Justin, as we get to know each other, you will find I am not the average user :-) So guys, to illustrate my point about high rez native streaming, there have been some posts on Subsonic forum about the downsampling of iSub when using digital out to an outboard DAC from a mobile device - i.e., evidence showed that when trying to play a native 24bit/96kHz file for instance from iSub thru the CCK to an outboard DAC, that iSub and Vox were both downsampling the file to 16bit/44.1kHz. There are apps like Hibiko and Onkyo’s app that specifically do not downrez at all in the same situation. Also, it appears that as of several days ago, the author of AVSub for iOS has gotten it working, though there is some dispute of this…reference these 2 threads for the drama:

http://forum.subsonic.org/forum/viewtopic.php?f=8&t=16295

http://forum.subsonic.org/forum/viewtopic.php?f=8&t=15788

This is what Ben and I were going back and forth on, the ability to not only not down-rez when the native iPhone DAC is used (how most will use it of course), but also the ability to not down-rez when someone connects an outboard DAC to their phone (like the Oppo HA-2 or 15 other devices one can buy for this purpose), and of course this person wants to stream the full high resolution of the files they are paying dearly for (high rez FLAC can be 25 bucks per album for instance, DSD even higher). I have tons of both if anyone wants to test.

Thanks guys.

On Feb 3, 2016, at 2:00 PM, Justin Hill notifications@github.com wrote:

You absolutely can disable transcoding in settings, and iSub will play whatever comes back from Subsonic, but you can imagine that less savvy users would be very pissed off if iSub caused them to go over their monthly bandwidth allotments. I was merely hypothesizing a cause based on your description of the symptoms. Going off of Ben's agreement with my assessment, I don't think this was an unreasonable first stab lol.


Reply to this email directly or view it on GitHub.

@einsteinx2
Copy link
Owner

Hmm I was under the impression that the iPhone was limited to 24bit 48kHz output regardless of output method as a hardware limitation. However, maybe that only applies to older devices. The BASS library as I understand it utilizes the normal iOS audio APIs underneath and just handles decoding (except for MP3/AAC which it uses the iOS built in hardware decoding method).

How they can enable higher output via a USB DAC I'm not sure, as I don't have one to test with anyway. But it's something I can look into. I'm interested in iSub supporting all possible media formats in their pure form (regardless of my own lack of ability to ABX test anything above V0 mp3--believe me I've tried and yes I have high quality equipment). I do have a friend that can reliably ABX test 320 mp3 and flac, so I know it's possible for some people.

Since this thread contains more info about the high res playback than it does the original problem, I'm re-opening and have edited the title to reflect that.

However out of curiosity, what was the original problem?

@einsteinx2 einsteinx2 reopened this Feb 3, 2016
@elduderino5k
Copy link
Author

Nope, hasn’t been limited for a while on that. Any of the last 2-3 years worth of iOS devices can output much higher - now, with many DAC devices, you have to use the Camera Connecion Kit to do it, but with for instance the Oppo HA-2 you do not. Tell your former employer to buy you an HA-2 ($299 bucks) for all your hard work, they were quite lucky to have you there, right?! Nahh, but seriously, it’s a great little device and would assist you guys in your efforts longer term. Just a thought!

On Feb 3, 2016, at 2:38 PM, Ben Baron notifications@github.com wrote:

Hmm I was under the impression that the iPhone was limited to 24bit 48kHz output regardless of output method as a hardware limitation. However, maybe that only applies to older devices. The BASS library as I understand it utilizes the normal iOS audio APIs underneath and just handles decoding (except for MP3/AAC which it uses the iOS built in hardware decoding method).

How they can enable higher output via a USB DAC I'm not sure, as I don't have one to test with anyway. But it's something I can look into. I'm interested in iSub supporting all possible media formats in their pure form (regardless of my own lack of ability to ABX test anything above V0 mp3--believe me I've tried and yes I have high quality equipment). I do have a friend that can reliably ABX test 320 mp3 and flac, so I know it's possible for some people.

Since this thread contains more info about the high res playback than it does the original problem, I'm re-opening and have edited the title to reflect that.

However out of curiosity, what was the original problem?


Reply to this email directly or view it on GitHub.

@einsteinx2
Copy link
Owner

Sweet, looks like that will make a great test device. I'll hold off until I start working on this to order one, maybe I'll get lucky and the price will drop a bit.

I'm 100% interested in supporting this though. It's always been my intention for iSub to be the absolute best audio player for iOS functionality-wise, and this kind of stuff is top on my list. I want iSub to be THE niche audio player that everyone recommends.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants