• 1
  • 2(current)
  • 3
  • 4
  • 5
  • 12
PAPlayer (PAP) in XBMC CVS, what is it?
#16
grrrr. it was started being coded less than a week ago - ok?

don't expect it to be perfect just yet. be patient.

and yes, that bug has already been fixed.
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


Image
#17
it was meant to motivate u guys. just kidding. keep up the good work
real_men_don't_need_spacebars.
#18
hello.

i haven't seen it posted anywhere else yet, but for folks following this thread, i thought it would be worth mentioning that the latest build supports gapless playback with paplayer/in_mp3.dll.  i've checked it out and it's really nice.  go grab a new build and see for yourself!
#19
yeah, and it's quite solid too, and lets not forget the audible ff/rew, working cuesupport for both cbr and vbr & gapless glory

all it's missing is a couple of more input plugins, replaygain support maybe and we have a nice musiccore imho
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


Image
#20
thanks guys !! - this has been one of the annoyances which i thought we were stuck with...

who knows we may be on the road to a xbmc 1.2 and bug bash !!
#21
amazing work guys, i'm very impressed with the new audio core. gapless, vbr, all working great.

i really am very impressed.
#22
yess, great work!!! i was waiting for this.
real_men_don't_need_spacebars.
#23
paplayer is a very welcome improvement. gapless playback and the audible seeking is excellent.

has anyone else noticed an occassional hiccup in playback with it though? every once in a while there will be a slight skip. is paplayer interacting with the buffer differently? i'm on a wireless network (54g), so the stutter is probably somehow related. the reason i bring it up is that mplayer has never stuttered during playback since xbmc's conception (what, 1.5 years ago?)
#24
the replaygain support is very welcomed. hopefully apev2 tags will be supported soon (apparently being worked on since the ape codec has been added to paplayer).
#25
(aron parsons @ april 25 2005,07:26 Wrote:has anyone else noticed an occassional hiccup in playback with it though?  every once in a while there will be a slight skip.
i just compiled a new build ("added: codec factory for paplayer " being the latest addition to the changelog). i can confirm this is happening.
I'm the one currently maintaning the Norwegian translation. Please drop me a message if you find errors or room for improvement.
#26
(vnm @ may 01 2005,21:14 Wrote:
(aron parsons @ april 25 2005,07:26 Wrote:has anyone else noticed an occassional hiccup in playback with it though? every once in a while there will be a slight skip.
i just compiled a new build ("added: codec factory for paplayer " being the latest addition to the changelog). i can confirm this is happening.
i'll post an entry in the 'bugs' forum; it'll probably be faster to get jmarshall's attention than a sf bug.
#27
i can also confirm the bug and it is not related ot the wireless network. even f yoiu increase the cache level it still happens. no stuttering experienced with mplayer and video...
#28
i've tested many mp3s and havent been able to reproduce yet, we are talking mp3 i guess Huh
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


Image
#29
yes, mp3s. my mp3s are all vbr encoded with lame aps or apx. as others stated, the stuttering does not occur with mplayer.
#30
all:

cache means nothing to paplayer.

with mp3's we have the following memory blocks in use:

1. 64k read buffer for the mp3 file.

2. 4 frame (1152*4*4) buffer in the codec itself to allow for gapless playback.

3. 2 second buffer in the paplayer itself, of which at least 1 second is almost always full.

4. 1 second final output buffer.

with these, i have never had a single issue at all, but i am running over smb on a wired network.

perhaps we need additional buffers at either steps 1 or 3 (as these are what slow networks would produce.

to be honest though, reading from network should not be a problem at all with mp3 - the required datarate is so slow.

note that i've also never had issues with ape which have a much higher datarate.

i may add some more debugging output. trouble is it's very hard to add efficient targetted debugging without knowing what is causing this exactly.

cheers,
jonathan
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


Image
  • 1
  • 2(current)
  • 3
  • 4
  • 5
  • 12

Logout Mark Read Team Forum Stats Members Help
PAPlayer (PAP) in XBMC CVS, what is it?0