UltraSonic for Android (1.2.0.7 / 2013/07/20)

[@dennislee]

Hi Archrival,

I love your mod for the Starred Albums/Songs feature but I'm also encountering the "receive incoming msg = resume play/Bluetooth media buttons" problem. After disabling it and rebooting it stops. I'm running a Samsung Note 1 unmodded and using Parrot Ziks as my bluetooth headset. Also, when I did have the media buttons turned on, the Ziks did not have their volume/track controls enabled (but I'm not sure how they're mapped in the first place, so it's not a big issue).

[bkrodgers]

I like where this is headed, but I can't try out the app because it says I need to upgrade my server. I'm using 4.7 with music cabinet

Hmm. 4.7 should provide an appropriate REST API level. I have not used music cabinet though.

Sent from my HTC6435LVW using Tapatalk 2

It looks like music cabinet only has the 1.7 REST API. I guess it's not fully based on 4.7.

How hard would it be to add support for the 1.7 REST API to your client? If it 's not something you're interested in spending time on, I may work on it and submit a patch. I haven't looked at the differences between 1.7 and 1.8 yet. Do you think it's a big deal to do? I'll also ask over in the music cabinet forum about getting the REST API up to 1.8, but I'd imagine that might take more time.

[archrival]

I didn't support API versions prior to 1.8.0 because I didn't want to worry about servers that didn't support the star capabilities. No backwards compatibility is much easier, obviously.

Sent from my HTC6435LVW using Tapatalk 2

[archrival]

Hi Archrival,

I love your mod for the Starred Albums/Songs feature but I'm also encountering the "receive incoming msg = resume play/Bluetooth media buttons" problem. After disabling it and rebooting it stops. I'm running a Samsung Note 1 unmodded and using Parrot Ziks as my bluetooth headset. Also, when I did have the media buttons turned on, the Ziks did not have their volume/track controls enabled (but I'm not sure how they're mapped in the first place, so it's not a big issue).

I am looking into the media buttons problem, but life has slowed down development the last few weeks. Hopefully I will have something this week.

Sent from my HTC6435LVW using Tapatalk 2

[rubbersoul]

have you looked into the playback bug on first track at all? It's been around for some time now. If you play a song that is currently downloading it will stutter during playback once or twice. if you play an already downloaded song it doesn't seem to have a problem. I know you mentioned working on gapless playback, so maybe you'd be interested in this bug as well. It is a problem with both dsub and subsonic. The dsub guy took a stab at fixing it but to no avail. haven't seen a response from Sindre about it.

[mr_nobody]

have you looked into the playback bug on first track at all? It's been around for some time now. If you play a song that is currently downloading it will stutter during playback once or twice. if you play an already downloaded song it doesn't seem to have a problem. I know you mentioned working on gapless playback, so maybe you'd be interested in this bug as well. It is a problem with both dsub and subsonic. The dsub guy took a stab at fixing it but to no avail. haven't seen a response from Sindre about it.

In fact, with the recent buffer=0 setting in dsub, it is fixed as long as you are okay with downloading the whole track before it starts playing.

[rubbersoul]

Yeah, that works ok when I've got a really speedy connection since I don't have to wait too long but it's not the ideal solution. Google Music and audiogalaxy don't have this problem so it isn't a limitation of Android. Not sure how subsonic handles this differently

[hakko]

It looks like music cabinet only has the 1.7 REST API. I guess it's not fully based on 4.7.

How hard would it be to add support for the 1.7 REST API to your client? If it 's not something you're interested in spending time on, I may work on it and submit a patch. I haven't looked at the differences between 1.7 and 1.8 yet. Do you think it's a big deal to do? I'll also ask over in the music cabinet forum about getting the REST API up to 1.8, but I'd imagine that might take more time.

I might add here that even though a MusicCabinet server reports itself as version 1.7, it does expose the methods necessary for starring in the REST API. Other methods from the 1.8 update are not (yet) implemented, so it seems more appropriate to report 1.7 as version. In this case, it comes out sub-optimal as you could actually do the starring if the version wasn't checked.

[pioneersohpioneers]

Great update ArchRival!

I originally came to post about the notification bug, but I see that has been mentioned.

The other big issue I've noticed is that the app will hang the first time I open it after a while (think first launch after waking up in the morning). I have to wait until android asks if I want to force close the app, on next launch it works.

Lastly, I think the device is causing pretty constant wakelocks when playing music, but i'm not sure i'm interpreting BetterBatteryStats correctly. I've got AudioOut_2 , android.media.MediaPlayer and net.sourceforge.subsonic.androidapp.service.DownloadServiceImpl as Partial Wakelocks.

By the way, I'm running JB 4.2.1 on an HTC Rezound (IAmTheOneCalledNeo's Infectious Rezound ROM). I believe these issues are present in the stock App, so I'm thinking this is an issues with 4.2 compatibility?

Give me the tl;dr on how to snag the correct logcat and I can get that to you.

[pioneersohpioneers]

Lastly, I think the device is causing pretty constant wakelocks when playing music, but i'm not sure i'm interpreting BetterBatteryStats correctly. I've got AudioOut_2 , android.media.MediaPlayer and net.sourceforge.subsonic.androidapp.service.DownloadServiceImpl as Partial Wakelocks.

Upon further review, it seems the AudioOut_2 wakelock is a ROM issue

[daneren2005]

Great update ArchRival!

I originally came to post about the notification bug, but I see that has been mentioned.

The other big issue I've noticed is that the app will hang the first time I open it after a while (think first launch after waking up in the morning). I have to wait until android asks if I want to force close the app, on next launch it works.

Lastly, I think the device is causing pretty constant wakelocks when playing music, but i'm not sure i'm interpreting BetterBatteryStats correctly. I've got AudioOut_2 , android.media.MediaPlayer and net.sourceforge.subsonic.androidapp.service.DownloadServiceImpl as Partial Wakelocks.

By the way, I'm running JB 4.2.1 on an HTC Rezound (IAmTheOneCalledNeo's Infectious Rezound ROM). I believe these issues are present in the stock App, so I'm thinking this is an issues with 4.2 compatibility?

Give me the tl;dr on how to snag the correct logcat and I can get that to you.

I'm pretty sure that I already fixed that, archrival just needs to setup the CacheCleaner to run as a background task on startup. I think there was another thing that I had to throw in a background task, but I can't for the life of me remember it right now. I know the CacheCleaner was the big one though.

[archrival]

Minor release: 3.9.9.15

Just an interim release while I research the issues mentioned in the thread.

[archrival]

Minor release: 3.9.9.16

I believe I have solved the playback issue that was occurring when a notification sound was played. I was starting the audio once audio focus had been regained, regardless of the previous playback state. This has been fixed, give it a shot. I also fixed some other minor issues.

[pioneersohpioneers]

Minor release: 3.9.9.16

I believe I have solved the playback issue that was occurring when a notification sound was played. I was starting the audio once audio focus had been regained, regardless of the previous playback state. This has been fixed, give it a shot. I also fixed some other minor issues.

Seems to have fixed the notification issues on my phone! Thanks a lot for your hard work

[archrival]

Minor release: 3.9.9.17

According to my research, for whatever reason, the MediaPlayer API in Android has no ability to be told a file path or file descriptor is downloading so it will only play up to the location in the track at the time setDataSource() is called. The previous Subsonic code would listen for the playback complete status and determine if the whole track had been played, continuing playback as many times as necessary to complete the track. This caused the stutter or pause in playback when playing the file as it was being downloaded.

Using an HTTP URL allows the MediaPlayer to buffer the file as it is downloaded. This gives us the ability to not only show progress in the playback progress slider, but more importantly, allows the track to be played in it's entirety without pauses or stutters. Assuming the track can be downloaded faster than it can be played. We don't want to have 2 simultaneous streams, 1 for saving to disk and 1 for playback, so an alternate solution is needed. Thankfully, some has already created one. I have switched to using StreamProxy (using code/ideas from both http://code.google.com/p/npr-android-app/source/browse/Npr/src/org/npr/android/news/StreamProxy.java?r=e4984187f45c39a54ea6c88f71197762dbe10e72 and http://stackoverflow.com/questions/5343730/mediaplayer-stutters-at-start-of-mp3-playback/5432091#5432091). This actually sets up a tiny, simplistic web server which is used to stream music from the cache as it is downloading via HTTP.

This is a first release with this playback mechanism, there are bound to be bugs. I'm also not sure how this works when transcoding. However, it works great for me. Please give this new version a shot and let me know how it works.

EDIT: Offline playback is broken in this build. Will fix.