Jump to content


New Members
  • Content Count

  • Joined

  • Last visited

About c0derbear

  • Rank
  1. For my nickle, my audio listening is always done via local media for a number of reasons. - i live in an area with spotty wireless data support and I often going into back-country cycling or hiking where there is zero coverage (as in my phone gets set to airplane mode to conserve power) - my workplace does not have wifi and I don't want to abuse mobile data for streaming, not even audio - there are no DLNA servers in my life So, because of this, from the available Material design was the only option. What I want out of that is not that PA is "made bland" but that it works and renders well with the host device. I haven't used it long enough to have a real opinion about the current UI (other than it's no problem to operate and that's nice considering some players have just horribly complex UI). I have no head how much of this there has been, but power-consumption optimization would be something on my personal list, particularly at least understanding the change of power consumption impact in MM vs KK since battery endurance is always a factor. I can see from other users' POV that more active network-centric features would be attractive - streaming music from dropbox/drive/onedrive/et. al.; streaming from Google Play or Amazon or Itunes(?) - I recognize I live in a digital backwater - but if those features come at the cost of the base capabilities or induce excessive power when *not* in use then they're a non-starter for me. -t
  2. Nice work PA team. Good sound. Lean app. The audio quality has pulled me away from long-standing other player(s) usage, job well done. I listen a fair amount over both wired- and bt- devices, more-so over bt though so I was very happy when the HQ audio worked over BT in addition to wired. Only *quirk* I've experienced so far is two odd interactions with my car's head unit over BT. 1. PA starts playing on BT connect regardless of "resume" settings within PA I don't know but speculate that the head unit is sending some kind of startup trigger that is causing PA to start playing but don't really know. I am aware that other audio players (e.g. RocketPlayer) have a tweak setting to 'ignore initial play command on connect' (or words to that effect) and I wonder if PA could use something similar. The repro case goes like this: PA idle (playback stopped or paused). Phone may be screen-locked or not, doesn't matter. Start car, which fires up head unit and inities BT connection Switch head unit to BT audio No audio playback through car, however PA is *playing* - wake phone / unlock to verify Attempting to start playback on car is unreliable, it may work and then pause at the end of the song, or just not work at all Manually stop playback in PA Play controls in car will now work as expected (play, stop, skip, etc.) Flipping the PA "resume on connect..." settings does not appear help change the situation. This odd behavior does not happen with the BT headset I have at my desk at work (LG HBS-730 "Tone") so I do believe it is something that the head unit is doing which is causing the behavior. 2. Head unit does not always update the progress-bar through the song as they play The head unit progress meter counts up to 2 to 4 seconds of playback and stops. I theorize this may be caused by VBR tracks w/o ID3 but have not confirmed, I need to run down a test case. If that is a known-cause of this behavior it would be good to know. Thanks for your time and effort. Android device: Samsung Galaxy S7 Edge (SM-G935A, Snapdragon, USA=AT&T, stock Android 6.0.1, not rooted), current PA beta from Play Store Car head unit: VW OEM RCD510 (stock unit in 2013 VW Golf TDI) Secondary BT device: LG HBS-730 "Tone" headset
  3. Seems to work fine on my device both SW and SoX resamplers, Wired & BT. Samsung S7 Edge (SM-G935A, Snapdragon, Android 6.0.1)
  • Create New...