[livesupport-dev] latest results - Airtime Development Discussions on Sourcefabric Forum

import

This is a multipart message in MIME format.
--=_alternative 007290A4C125706B_=
Content-Type: text/plain; charset="us-ascii"

Hi,

My latest results with the newest LS build result in the following delays.

Files used are
Songs from Bebel Gilberto's "Tanto Tempo" : 160kbps ogg, 44.1khz
ads: 128kbps mp3, 22050hz
DJ Earworm's "Lick the Robot": 256kbps mp3, 44.1khz
Bob Marley's "Legend": 64kbps mp3, 44.1 khz

Playing a playlist made up of 2 files from Bebel Gilberto (duration:
7:18): 4 seconds delay
Playing a playlist made up of 3 ads (duration: 3:04): 10 seconds delay
Playing a playlist made up of a combination of music + ads (duration:
13:19): 14 seconds delay
Playing a playlist made up of 5 files from Bebel Gilberto (duration
13:15): 5 seconds delay
Playing a playlist made up of 12 files from Bob Marley (duration 50:27):
13 seconds delay

Granted, some of the files (the ads files are at 22050 and the Marley
files are at 64kbps, so I don't know if they count) I'm using are not to
the current standards, so I suppose we can rule their results out for the
time being.

Regardless, for the files that are in range (44.1 khz is the only current
requirement, as I understand it), the delays are improved, but still too
long.

Akos, I'm pretty sure you have some 'real world' mp3s or oggs somewhere in
your collection. I'd suggest using these in addition to your smil test
files to get us better triangulation.

doug

--=_alternative 007290A4C125706B_=
Content-Type: text/html; charset="us-ascii"

Hi,

My latest results with the newest LS build result in the following delays.

Files used are

Songs from Bebel Gilberto's "Tanto Tempo" : 160kbps ogg, 44.1khz

ads: 128kbps mp3, 22050hz

DJ Earworm's "Lick the Robot": 256kbps mp3, 44.1khz

Bob Marley's "Legend": 64kbps mp3, 44.1 khz

Playing a playlist made up of 2 files from Bebel Gilberto (duration: 7:18): 4 seconds delay

Playing a playlist made up of 3 ads (duration: 3:04): 10 seconds delay

Playing a playlist made up of a combination of music + ads (duration: 13:19): 14 seconds delay

Playing a playlist made up of 5 files from Bebel Gilberto (duration 13:15): 5 seconds delay

Playing a playlist made up of 12 files from Bob Marley (duration 50:27): 13 seconds delay

Granted, some of the files (the ads files are at 22050 and the Marley files are at 64kbps, so I don't know if they count) I'm using are not to the current standards, so I suppose we can rule their results out for the time being.

Regardless, for the files that are in range (44.1 khz is the only current requirement, as I understand it), the delays are improved, but still too long.

Akos, I'm pretty sure you have some 'real world' mp3s or oggs somewhere in your collection. I'd suggest using these in addition to your smil test files to get us better triangulation.

doug

--=_alternative 007290A4C125706B_=--

------------------------------------------
Posted to Phorum via PhorumMail

import

> Akos, I'm pretty sure you have some 'real world' mp3s or oggs somewhere in
> your collection. I'd suggest using these in addition to your smil test
> files to get us better triangulation.

still, could you send me a detailed description of the playlists you use?
like how long music files, what offsets are used (are they simply
sequential playlists?), etc...

------------------------------------------
Posted to Phorum via PhorumMail

import

> Akos, I'm pretty sure you have some 'real world' mp3s or oggs somewhere in
> your collection. I'd suggest using these in addition to your smil test
> files to get us better triangulation.

still, could you send me a detailed description of the playlists you use?
like how long music files, what offsets are used (are they simply
sequential playlists?), etc...

------------------------------------------
Posted to Phorum via PhorumMail

import

This is a multipart message in MIME format.
--=_alternative 000BC0A8C125706C_=
Content-Type: text/plain; charset="us-ascii"

The playlists are all simple sequential playlists with default offsets.
Here is the breakdown:

Ads 3 files, total duration: 03:04 -- 10 second delay
=====

1. Schlitz Beer 1:01 MP3, 24kb/s, Samplerate: 22050Khz
2. Palm Springs 1:04, MP3, 24kb/s, Samplerate: 22050 Khz
3. Toyota 1:00, MP3, 24Kb/s, Samplerate: 22050 Khz

Music 3 files, total duration 10:08 -- 5 second delay
=======
1. Lick the Robot, 4:11 MP3, 256Kbps, Samplerate: 44.1 khz
2. Lonely, 02:25 Ogg, 160kbps, Samplerate: 44.1 khz
3. So Nice (Summer Samba), 03:33 Ogg, 160 kbps, Samplerate: 44.1 khz

Bob Marley - Legend,12 files, total duration 50:27 -- 13 second delay
=======
1. No woman no cry, 7:07 MP3, 64Kbps, Samplerate: 44.1 khz
2. Get up stand up, 3:17 MP3, 64kbps, Samplerate: 44.1 khz
3. Satisfy my soul, 4:32 MP3, 64kbps, Samplerate: 44.1 khz
4. Jamming, 3:31 MP3, 64kbps, Samplerate: 44.1 khz
5. Three Little Birds, 3:00 MP3, 64kbps, Samplerate: 44.1 khz
6. Is This Love, 3:52 MP3, 64kbps, Samplerate: 44.1 khz
7: One Love/People Get Ready, 2:52 MP3, 64kbps, Samplerate: 44.1 khz
8. Redemption Song, 3:40 MP3, 64kbps, Samplerate: 44.1 khz
9: I Shot the Sheriff, 4:41 MP3, 64kbps, Samplerate: 44.1 khz
10. Stir It Up, 5:34 MP3, 64kbps, Samplerate: 44.1 khz
11. Could You Be Loved, 3:55 MP3, 64kbps, Samplerate: 44.1 khz
12. Buffalo Soldier, 4:17 MP3, 64kbps, Samplerate: 44.1 khz

Music + Ads, 3 files + 1 playlist, total duration 13:19 -- 14 second delay
=======
1. Lonely, 02:25 Ogg, 160 kbps, Samplerate: 44.1 khz
2. Ads (playlist, see above), duration: 3:05
3. So Nice (Summer Samba), 3:33 Ogg, 160 kbps, Samplerate: 44.1 khz
4. Mais Feliz, 4:17 Ogg, 160 kbps, Samplerate: 44.1 khz

darkeye@tyrell.hu
08/28/05 10:57 PM
Please respond to livesupport-dev

To: livesupport-dev@campware.org
cc:
Subject: Re: [livesupport-dev] latest results

> Akos, I'm pretty sure you have some 'real world' mp3s or oggs somewhere
in
> your collection. I'd suggest using these in addition to your smil test
> files to get us better triangulation.

still, could you send me a detailed description of the playlists you use?
like how long music files, what offsets are used (are they simply
sequential playlists?), etc...

--=_alternative 000BC0A8C125706C_=
Content-Type: text/html; charset="us-ascii"

The playlists are all simple sequential playlists with default offsets. Here is the breakdown:

Ads 3 files, total duration: 03:04 -- 10 second delay

=====

1. Schlitz Beer 1:01 MP3, 24kb/s, Samplerate: 22050Khz

2. Palm Springs 1:04, MP3, 24kb/s, Samplerate: 22050 Khz

3. Toyota 1:00, MP3, 24Kb/s, Samplerate: 22050 Khz

Music 3 files, total duration 10:08 -- 5 second delay

=======

1. Lick the Robot, 4:11 MP3, 256Kbps, Samplerate: 44.1 khz

2. Lonely, 02:25 Ogg, 160kbps, Samplerate: 44.1 khz

3. So Nice (Summer Samba), 03:33 Ogg, 160 kbps, Samplerate: 44.1 khz

Bob Marley - Legend,12 files, total duration 50:27 -- 13 second delay

=======

1. No woman no cry, 7:07 MP3, 64Kbps, Samplerate: 44.1 khz

2. Get up stand up, 3:17 MP3, 64kbps, Samplerate: 44.1 khz

3. Satisfy my soul, 4:32 MP3, 64kbps, Samplerate: 44.1 khz

4. Jamming, 3:31 MP3, 64kbps, Samplerate: 44.1 khz

5. Three Little Birds, 3:00 MP3, 64kbps, Samplerate: 44.1 khz

6. Is This Love, 3:52 MP3, 64kbps, Samplerate: 44.1 khz

7: One Love/People Get Ready, 2:52 MP3, 64kbps, Samplerate: 44.1 khz

8. Redemption Song, 3:40 MP3, 64kbps, Samplerate: 44.1 khz

9: I Shot the Sheriff, 4:41 MP3, 64kbps, Samplerate: 44.1 khz

10. Stir It Up, 5:34 MP3, 64kbps, Samplerate: 44.1 khz

11. Could You Be Loved, 3:55 MP3, 64kbps, Samplerate: 44.1 khz

12. Buffalo Soldier, 4:17 MP3, 64kbps, Samplerate: 44.1 khz

Music + Ads, 3 files + 1 playlist, total duration 13:19 -- 14 second delay

=======

1. Lonely, 02:25 Ogg, 160 kbps, Samplerate: 44.1 khz

2. Ads (playlist, see above), duration: 3:05

3. So Nice (Summer Samba), 3:33 Ogg, 160 kbps, Samplerate: 44.1 khz

4. Mais Feliz, 4:17 Ogg, 160 kbps, Samplerate: 44.1 khz

darkeye@tyrell.hu

08/28/05 10:57 PM

Please respond to livesupport-dev

To: livesupport-dev@campware.org

cc:

Subject: Re: [livesupport-dev] latest results

> Akos, I'm pretty sure you have some 'real world' mp3s or oggs somewhere in

> your collection. I'd suggest using these in addition to your smil test

> files to get us better triangulation.

still, could you send me a detailed description of the playlists you use?

like how long music files, what offsets are used (are they simply

sequential playlists?), etc...

--=_alternative 000BC0A8C125706C_=--

------------------------------------------
Posted to Phorum via PhorumMail

import

Douglas.Arellanes@mdlf.org wrote:
>
> 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 = 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?

------------------------------------------
Posted to Phorum via PhorumMail

import

This is a multipart message in MIME format.
--=_alternative 0045766BC125706C_=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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.

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:

using configuration file: /opt/livesupport/etc/gLiveSupport.xml
using config file '/opt/livesupport/etc/gLiveSupport.xml'
./gLiveSupport.sh: line 57: 17179 Aborted $gLiveSupport=5Fexe -c=20
$config=5Ffile

I'll be a lot more relieved if this behavior is something specific to my=20
machine, rather than something more general with LS.

doug

=C1kos Mar=F3y
08/29/05 02:15 PM
Please respond to livesupport-dev

=20
To: livesupport-dev@campware.org
cc:=20
Subject: Re: [livesupport-dev] latest results

Douglas.Arellanes@mdlf.org wrote:
>=20
> 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=20
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_=
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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 the access times? I haven't seen that=
, perhaps because I'm getting a segfault when I let a file play to the end.=
Here's the message the console is giving:

using configuration file: /opt=
/livesupport/etc/gLiveSupport.xml

using config file '/opt/livesupport/=
etc/gLiveSupport.xml'

./gLiveSupport.sh: line 57: 17179 Ab=
orted $gLiveSupport=
=5Fexe -c $config=5Ffile

I'll be a lot more relieved if this =
behavior is something specific to my machine, rather than something more ge=
neral with LS.

doug

=C1kos Mar=F3y <darkeye@tyrell=
.hu>

08/29/05 02:15 PM

Please respond to livesupport-dev ont>

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

Vote Up0Vote Down

import April 2010

Posts: 0Member

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

Vote Up0Vote Down

import April 2010

Posts: 0Member

Vote Up0Vote Down

import April 2010

Posts: 0Member

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

Vote Up0Vote Down

import April 2010

Posts: 0Member

On Mon, 29 Aug 2005 16:29:11 +0200

Vote Up0Vote Down

import April 2010

Posts: 0Member

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

Vote Up0Vote Down

import April 2010

Posts: 0Member

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>

=C1kos Mar=F3y <darkeye@tyrell=
.hu>

08/29/2005 06:04 PM

Please respond to livesupport-dev ont>

To: &nbs=
p; livesupport-dev@campware.org

cc: &nbs=
p;

Subject:=
Re: [livesupport-dev] latest results ble>

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_=--

------------------------------------------
Posted to Phorum via PhorumMail

Add a Comment

Start a New Discussion

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Sign In Apply for Membership

Poll

No poll attached to this discussion.

Howdy, Stranger!

Categories

Poll

Top Posters