darkeye@tyrell.hu 08/28/05 10:57 PM | To: livesupport-dev@campware.org cc: Subject: Re: [livesupport-dev] latest results |
=C1kos Mar=F3y <darkeye@tyrell= .hu> 08/29/05 02:15 PM | To: &nbs= p; livesupport-dev@campware.org cc: &nbs= p; Subject:= Re: [livesupport-dev] latest results ble> Douglas.Arellanes@mdlf.org wrote: r> > > The playlists are all simple sequential playlists with default offsets= . > Here is the breakdown: I did some experiments on my own. I made a playlist with four J.S. Bach files, totallying about 34 minutes. the opening time for this playlist is 0.7 seconds on my machine (1.8 GHz centrino) but, how are you opening the files? I tested trying to play them from the GUI scratchpad, and it indeed takes longer. but the time is not spent moslty on opening. the following calls are made then the play button is pressed in the scratchpad:= cueItemPlayingNow = =3D storage->acquirePlaylist(sessionId, playable->getId()); cuePlayer->open(= *cueItemPlayingNow->getUri()); cuePlayer->start= (); the times for the above are: acquire duration: 00:00:01.389374 open duration: 00:00:00.831224 start duration: 00:00:00.044801 so, most of the time spent is for acquiring the playlist from the storage. maybe we should open the files as soon as they appear in the scratchpad? how did you test these files? where / how did you play them? --=_alternative 0045766BC125706C_=-- ------------------------------------------ Posted to Phorum via PhorumMail
Douglas.Arellanes@mdlf.org wrote:
> > I'm on a 1.1 Ghz PIII, and am opening the playlists by first putting an > file in LS Studio Live Mode, then hitting the 'stop' button, which > should stop the current file playing and load the playlist in for > playing. That's taking me 7-8 seconds after hitting the 'stop' button. I tested my same Bach playlist in live mode as well. Basically it's the same procedure that happens when playing from the scratchpad. the times are: acquire duration: 00:00:01.176643 open duration: 00:00:00.858749 start duration: 00:00:00.044173 this means that the most time is spent on opening the playlist and all related files. maybe Ferenc could optimize the process by opening files earlier (maybe as they are 'selected' in the scratchpad or anywhere else?). ------------------------------------------ Posted to Phorum via PhorumMail
Stefan de Konink wrote:
> Is the parsing the actual problem or the reading process? it's a client-server achitecture, the files are accessed through XML-RPC from the storage server... ------------------------------------------ Posted to Phorum via PhorumMail
On Mon, 29 Aug 2005 16:29:11 +0200
Tomas Hlava wrote:
> XML-RPC::locstor.accessRawAudioData XML-RPC is used, I guess accessRawAudioData but you can fire up the GUI, and then trace what calls are made. Doug can give you details on how to replicte the test scenario.. Akos ------------------------------------------ Posted to Phorum via PhorumMail
This is a multipart message in MIME format. --=_alternative 0058927CC125706C_= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The test files I've used are up on my site; I'm copying and pasting my=20 previous mail here. The source materials are up on my site at=20 http://www.arellanes.com/livesupport, but I'm sure that any MP3s or oggs=20 at 128-192 kbps and 44.1 khz should be ok for testing. -- doug I'm on a 1.1 Ghz PIII, and am opening the playlists by first putting an=20 file in LS Studio Live Mode, then hitting the 'stop' button, which should=20 stop the current file playing and load the playlist in for playing. That's = taking me 7-8 seconds after hitting the 'stop' button.=20 Does waiting for a playlist item to end officially make any difference in=20 the access times? I haven't seen that, perhaps because I'm getting a=20 segfault when I let a file play to the end. Here's the message the console = is giving:=20 using configuration file: /opt/livesupport/etc/gLiveSupport.xml=20 using config file '/opt/livesupport/etc/gLiveSupport.xml'=20 ./gLiveSupport.sh: line 57: 17179 Aborted $gLiveSupport=5Fexe -c=20 $config=5Ffile=20 I'll be a lot more relieved if this behavior is something specific to my=20 machine, rather than something more general with LS.=20 I've tried some additional bitrates, but keeping the samplerate at=20 44.1khz.=20 Playlist: Donald Byrd (Duration: 45:44, 7 files, standard fades, all files = 320kbps MP3); -- delay 8 sec.=20 1. Street Lady 5:42=20 2. Wind Parade 6:11=20 3. Places and Spaces 6:22=20 4. You and Music 5:23=20 5. Flight Time 8:31=20 6. Think Twice 6:13=20 7. Blackbyrd 7:22=20 For reference, files can be downloaded from http://www.arellanes.com/livesu= pport/test=5Ffiles/Donald Byrd - Best of Donald Byrd=20 Playlist: Mashups (Duration: 25:25, 5 files, standard fades, all files=20 256kbps MP3); -- delay 8 sec.=20 1. Brazil is Full of Love 6:35=20 2: Lick the Robot 4:11=20 3. Jesus is my personal trainer 4:59=20 4. Policy of Sweet Dreams 4:43=20 5: Let Jolene Enjoy the Music In Silence 4:57=20 for reference, these files can be downloaded from http://www.arellanes.com/= livesupport/earworm=20 =C1kos Mar=F3y 08/29/2005 06:04 PM Please respond to livesupport-dev =20 To: livesupport-dev@campware.org cc:=20 Subject: Re: [livesupport-dev] latest results Tomas Hlava wrote: > XML-RPC::locstor.accessRawAudioData XML-RPC is used, I guess accessRawAudioData but you can fire up the GUI, and then trace what calls are made. Doug can give you details on how to replicte the test scenario.. Akos --=_alternative 0058927CC125706C_= Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The test files I've used are up on m= y site; I'm copying and pasting my previous mail here. The source materials= are up on my site at http://www.arellanes.com/livesupport, but I'm sure th= at any MP3s or oggs at 128-192 kbps and 44.1 khz should be ok for testing. = -- doug <snip> I'm on a 1.1 Ghz PIII, and am openin= g the playlists by first putting an file in LS Studio Live Mode, then hitti= ng the 'stop' button, which should stop the current file playing and load t= he playlist in for playing. That's taking me 7-8 seconds after hitting the = 'stop' button. Does waiting for a playlist item to end officially make any difference in t= he access times? I haven't seen that, perhaps because I'm getting a segfaul= t when I let a file play to the end. Here's the message the console is givi= ng: using configuration file: /opt/livesupport/etc/gLiveSupport.xml > s-serif"> using config file '/opt/livesupport/etc/gLiveSupport.xml' =3D3 face=3D"Times New Roman"> r> ./gLiveSupport.sh: line 57: 17179 Aborted  = ; $gLiveSupport=5Fexe -c $config=5Ffile ze=3D3 face=3D"Times New Roman"> I'll be a lot more relieved if this behavior is something specific to my ma= chine, rather than something more general with LS. e=3D"Times New Roman"> </snip> <snip> I've tried some additional bitrates,= but keeping the samplerate at 44.1khz. New Roman"> Playlist: Donald Byrd (Duration: 45:44, 7 files, standard fades, all files = 320kbps MP3); -- delay 8 sec. > 1. Street Lady 5:42 <= font size=3D2 face=3D"sans-serif"> 2. Wind Parade 6:11 <= font size=3D2 face=3D"sans-serif"> 3. Places and Spaces 6:22 = font> 4. You and Music 5:23 > 5. Flight Time 8:31 <= font size=3D2 face=3D"sans-serif"> 6. Think Twice 6:13 <= font size=3D2 face=3D"sans-serif"> 7. Blackbyrd 7:22 For reference, files can be downloaded from http://www.arellanes.com/livesu= pport/test=5Ffiles/Donald Byrd - Best of Donald Byrd ace=3D"Times New Roman"> Playlist: Mashups (Duration: 25:25, 5 files, standard fades, all files 256k= bps MP3); -- delay 8 sec. = font> 1. Brazil is Full of Love 6:35 "> 2: Lick the Robot 4:11 t> 3. Jesus is my personal trainer 4:59 Roman"> 4. Policy of Sweet Dreams 4:43 "> 5: Let Jolene Enjoy the Music In Silence 4:57 Times New Roman"> for reference, these files can be downloaded from http://www.arellanes.com/= livesupport/earworm </snip>
|