Re: Play from Audio CD
Re: Play from Audio CD
- Subject: Re: Play from Audio CD
- From: Brian Willoughby <email@hidden>
- Date: Fri, 11 Jun 2010 20:34:57 -0700
On Jun 11, 2010, at 18:25, John Johnson wrote:
The reason is that the ripped audio data can easily span several
hundred megabytes (or more) for longer songs. The ripper chugs
along ripping the data and passes it to the delegate, but the audio
player doesn't play the data as fast as it rips it, so I could
easily end up with >200 MB sitting in an audio buffer waiting to be
played. I'm not sure if this is a big issue or not with the amount
of memory available on Macs nowadays, but I can picture a user
trying to play an audio track that is 30 minutes (or 3 GB in size
when ripped) and experiencing a huge failure because they run out
of memory.
I could do it the other way around and ask the ripper for data as I
need it, but I'm also trying to achieve fast seek times, and I'm
not sure it would be possible to buffer ahead if I'm only asking
for data when I need it.
I wouldn't recommend this, because you want your ripper to access the
data sequentially. You don't want your playback position to cause
the optical drive to seek, because that will slow everything down
significantly.
And I have looked at the way iTunes does it, but there are also
other programs that DO allow you to play the file before it's fully
ripped, and they do it by writing a cache file. I've monitored this
using fseventer and other tools. Which leads me to believe that
this is possible.
It would be ideal to play back from memory, and if you have
suggestions on how to get around the memory issue, I'm definitely
open to hearing them. Honestly, I think it's much faster and tidier
to do it all from memory, and with most audio tracks only typically
being ~50MB in size when ripped, it's definitely viable. But I just
remember the fact that users do what you least expect when they
have your program in their hands.
OSX is quite efficient with virtual memory, and we're talking about
800 MB maximum. You shouldn't need to write a cache file, because
virtual memory will be more efficient. Perhaps you could keep only
one song in memory and then reuse the buffer as soon as the next song
is available, perhaps even switching to file-based playback as files
are finished writing. You have a lot of options.
Brian Willoughby
Sound Consulting
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden