Skip to search.

Breaking News Visit Yahoo! News for the latest.

×Close this window

pjrcmp3dev · PJRC MP3 Player Developers

The Yahoo! Groups Product Blog

Check it out!

Group Information

  • Members: 200
  • Category: Electrical
  • Founded: Jul 12, 2001
  • Language: English
? Already a member? Sign in to Yahoo!

Yahoo! Groups Tips

Did you know...
Hear how Yahoo! Groups has changed the lives of others. Take me there.

Messages

Advanced
Messages Help
Messages 992 - 1021 of 1369   Oldest  |  < Older  |  Newer >  |  Newest
Messages: Show Message Summaries Sort by Date ^  
#992 From: "ftouanen" <ftouanen@...>
Date: Fri Jun 6, 2003 8:20 am
Subject: Digital line with the STA3
ftouanen
Send Email Send Email
 
Hi,

In some BMW cars, the audio input is a 48Khz digital line (DSP
option).  I have seen the STA3 can provide this can of signal but
don't well this chip.
How to provide this kind of output  ?

Thanks.

Franck.

#993 From: "Williams, Matt" <mwilliams@...>
Date: Mon Jun 9, 2003 7:05 pm
Subject: PPC emulator project
ophbalance
Send Email Send Email
 
For those following along, have now put the
source for my eVB, an installer, and the .HEX
file the player is required to use for this
to work.

http://web.newsguy.com/ophbalance.

It can be found in the download section.  I DO
plan on making everything more stable, usible,
etc. when I'm able to find more free time ;).

Ophbalance
Matthew Williams

#994 From: "Tom Parker" <tparker@...>
Date: Tue Jun 10, 2003 12:27 pm
Subject: Ethernet progress
tom_wiresnco...
Send Email Send Email
 
Paul,

I'm making good progress on the ethernet interface, but I've hit a bit on an
electrical
snag that I'm a bit puzzled by.

At the moment I'm porting my ethernet interface code
(http://www.wiresncode.com/projects/ether) to use the fpga interface to access
the cs8900
chip.  Progress here has been good, the code finds and initialises the chip ok
(eg. I've
got a LED on one of the general purpose I/O chips that I can control).  The chip
is
interrupting the CPU ok, but at this point I'm having some trouble and I think
it's
electrical (I was having before the interrupting, I added the interrupt to
follow the
cs8900 example code to the letter).

The problem is that I'm seeing a glitch on the AEN (on the logic analyser) about
20ns
after the falling edge of the IOR signal.  I can only see the glitch on the AEN,
a NANDed
version of the two chip selects, not on the selects themselves.  At the moment
I'm
suspecting some kind of noise margin thing that the logic analyser can't see
(cause I'm
going from 3.3v to 5v).  Unfortunately my CRO is too slow to get a usable signal
(I can
see a blip in the CS line around the time of the IOR, but I can't get close
enough).  I'm
hoping to borrow a high speed CRO tonight.  This glitch is seen by the cs8900
because it
deactivates the IOCS16 output briefly (indicating the an invalid 16 bit xfer). 
I'm also
going to buy a few different logic varieties today to see if that improves
things (I've
tried HCT and ACT).  It might be that this device should be 3v powered, this
will be a
pain if so.

The odd things is that this only happens for certain registers, I haven't been
able to pin
this down further.  The packet page configuration address and data registers are
ok, but
the packet data and interrupt status queue registers are problematic.  I was
able to
kludge something up and read an almost complete packet from the cs8900, but it
was missing
the first few bytes.  Since the packet is passing the ethernet CRC, I'm assuming
the
problems are on the CPU side.

Anyway, my next step is to kludge the ethernet address logic into the schematic
fpga and
try it as an alternative.

I've put some photos and a bit of a project diary at
http://www.wiresncode.com/projects/pjrcmp3/ethernet/ - when you get a chance
pls. update
your projects page and the memory map to point here.  The addresses in the
memory map
should definately be 0xffe0 - 0xffef.

Cheers,
Tom



----------------------------------
Tom Parker tparker@...
http://www.wiresncode.com/projects

#995 From: "ftouanen" <ftouanen@...>
Date: Mon Jun 16, 2003 5:51 pm
Subject: Bug in "previous list" function
ftouanen
Send Email Send Email
 
Hi All,

I have seen at many times a crash in my player with the last CVS
version.  When the player startup, if it is the first directory of
the tree which is playing, when i press prev_list, the player crash.
You can try to forward (nxt_list) then prev_list until you crash.
It is not systematic, but surrounds often enough to catch it.

I can reproduce that with my own firmware and the official one.
Sorry, no logs at the moment.

Franck.

#996 From: "Williams, Matt" <mwilliams@...>
Date: Mon Jun 16, 2003 5:53 pm
Subject: RE: Bug in "previous list" function
ophbalance
Send Email Send Email
 
Franck,

It'd probably be a good idea to post a log of
this happening, which is what Paul will eventual
say anyway;).  Does it happen in all play modes?
One play mode?  It helps to have as much
information as possible.  Next/Prev playlist
was always kind of flakey for me, but then I
never really had need to use it.

Ophbalance
Matthew Williams

-----Original Message-----
From: ftouanen [mailto:ftouanen@...]
Sent: Monday, June 16, 2003 1:52 PM
To: pjrcmp3dev@yahoogroups.com
Subject: [pjrcmp3dev] Bug in "previous list" function


Hi All,

I have seen at many times a crash in my player with the last CVS
version.  When the player startup, if it is the first directory of
the tree which is playing, when i press prev_list, the player crash.
You can try to forward (nxt_list) then prev_list until you crash.
It is not systematic, but surrounds often enough to catch it.

I can reproduce that with my own firmware and the official one.
Sorry, no logs at the moment.

Franck.

#997 From: "veganinvt" <veganinvt@...>
Date: Sat Jun 21, 2003 7:19 pm
Subject: Idea
veganinvt
Send Email Send Email
 
Hi, I haven't viewed the code in-depth yet but I'll be trying to
make a general purpose file viewer, ie: *.txt, etc.
thanx, and I'll probably start tomorrow.
bye

#998 From: "colonwq" <colonwq@...>
Date: Tue Jun 24, 2003 5:14 pm
Subject: feature suggestion.....
colonwq
Send Email Send Email
 
What do you guys think of in order sorting the directory listing when
scanning the harddrive?

keith

#999 From: "besjr69" <besjr69@...>
Date: Wed Jun 25, 2003 8:19 am
Subject: Re: feature suggestion.....
besjr69
Send Email Send Email
 
Keith,

I've actually written code to do this but it significantly delays the
start up sequence.  I have over 600 playlist directories so it takes
quite a while.  Additionally, I get a lot of errors with memory
storage.  I am still working it.  Whenever I get done, I give you a
shot back.

Bobby
--- In pjrcmp3dev@yahoogroups.com, "colonwq" <colonwq@y...> wrote:
> What do you guys think of in order sorting the directory listing
when
> scanning the harddrive?
>
> keith

#1000 From: "Bernie Pallek" <bmatthiasp@...>
Date: Thu Jun 26, 2003 1:52 pm
Subject: Re: feature suggestion..... directory ordering/sorting
bmatthiasp
Send Email Send Email
 
Cool, I was about to start looking into this functionality myself.  In the
meantime, Keith, you may want to try what I've done.  There is a freeware
directory sorter that you can use to reorganize your FAT; it works under most
(probably all) Windows versions.  And remember, since it directly modifies the
FAT, there's some inherent risk.  ;)

http://home.earthlink.net/~darrelliu/articles/20020820-0.html

- bernie


--- In pjrcmp3dev@yahoogroups.com, "besjr69" <besjr69@y...> wrote:
> Keith,
>
> I've actually written code to do this but it significantly delays the
> start up sequence.  I have over 600 playlist directories so it takes
> quite a while.  Additionally, I get a lot of errors with memory
> storage.  I am still working it.  Whenever I get done, I give you a
> shot back.
>
> Bobby
> --- In pjrcmp3dev@yahoogroups.com, "colonwq" <colonwq@y...> wrote:
> > What do you guys think of in order sorting the directory listing
> when
> > scanning the harddrive?
> >
> > keith

#1001 From: "Bernie Pallek" <bmatthiasp@...>
Date: Thu Jul 3, 2003 8:28 pm
Subject: Interim fix for "buffer memory full" situation
bmatthiasp
Send Email Send Email
 
I wish I knew the firmware well enough to make the required fixes for supporting
unlimited file size/double buffering, but until I do, or it's done by someone
else, I have thought up an interim improvement.

If a buffer-full situation is detected, the player can fade the current song's
volume down, and restore it when the next song plays.  This will avoid an
unpleasant, jarring stop to the music when the buffer runs out.  It may result
in the disk-spin-up code being activated/completed as a bonus side-effect (I
don't think it's currently used, though there's some code there for it alredy).

I'm going to work on this idea in the next while, when I've got some free time. 
Any comments?

- bernie

#1002 From: "Bernie Pallek" <bmatthiasp@...>
Date: Mon Jul 7, 2003 7:05 pm
Subject: "Unlimited" file size, rewind, FF, etc support
bmatthiasp
Send Email Send Email
 
I don't know whether or not someone is working on supporting unlimited file
size, rewind, fast forward, etc... Paul commented some time ago about the plan
for pre-caching the next several songs, which is related.  Anyway, here are my
thoughts, in case anyone is interested in implementing stuff (if it's not
already underway):

- pre-cache the next 3 songs... 10 seconds each should be enough, but what if
user changes playmode during pre-cache or before pre-cached data is used?  (does
it invalidate the pre-cached data?)

- the "current" song should be double-buffered, to allow unlimited file size
playback, with "rewind" capability worked in by allowing playback routine to
fetch small cached blocks in a reverse order (eg. the first 512 bytes of each 4K
block or whatever); the buffers should use whatever free memory remains after
accounting for FAT storage/play lists, pre-cached next songs, other scratch
storage, etc

- fast-forward can just skip blocks of memory, nothing too fancy

- when skipping ahead to the next song, a quick-but-smooth volume fade would
sound better than an abrupt stop -- HOWEVER... there are some mix CDs that make
one track go directly into the next, so this fade-between tracks should be
optional/configurable .. or, better yet, it can do the quick fade only if user
presses "skip", but if the tracks proceed "naturally", no fade

Well, I'm sure there's stuff I missed, but I just wanted to get the ball rolling
(if it's not already).

- bernie

#1003 From: Paul Stoffregen <Paul@...>
Date: Tue Jul 8, 2003 7:03 pm
Subject: Re: "Unlimited" file size, rewind, FF, etc support
pauljs97140
Send Email Send Email
 
>
>
>I don't know whether or not someone is working on supporting unlimited file
size, rewind, fast forward, etc... Paul commented some time ago about the plan
for pre-caching the next several songs, which is related.  Anyway, here are my
thoughts, in case anyone is interested in implementing stuff (if it's not
already underway):
>
I am currently not working on this mp3 player project.  I hope to get
back into it later in the summer.

All of these wish-list items seem simple in concept, but involve quite a
bit of work on a lot of details.  For example, most of these involve
predictions of data consumption rates which don't really exist in the
code at this time, and are made more complex by the possibility of VBR
encoded mp3 files.

>- pre-cache the next 3 songs... 10 seconds each should be enough, but what if
user changes playmode during pre-cache or before pre-cached data is used?  (does
it invalidate the pre-cached data?)
>
>- the "current" song should be double-buffered, to allow unlimited file size
playback, with "rewind" capability worked in by allowing playback routine to
fetch small cached blocks in a reverse order (eg. the first 512 bytes of each 4K
block or whatever); the buffers should use whatever free memory remains after
accounting for FAT storage/play lists, pre-cached next songs, other scratch
storage, etc
>
>- fast-forward can just skip blocks of memory, nothing too fancy
>
>- when skipping ahead to the next song, a quick-but-smooth volume fade would
sound better than an abrupt stop -- HOWEVER... there are some mix CDs that make
one track go directly into the next, so this fade-between tracks should be
optional/configurable .. or, better yet, it can do the quick fade only if user
presses "skip", but if the tracks proceed "naturally", no fade
>
>Well, I'm sure there's stuff I missed, but I just wanted to get the ball
rolling (if it's not already).
>
Bernie, to get the ball rolling, you'll really need to get into the code
and start hacking.  Like most open-source project, actual hacking on the
code is the only way to move things along.

Even though I'm not currently dedicating time to this project, if you or
anyone else is making a serious attempt, I'll always find some bits of
time to help in small but important ways... like explaining how some
mysterious parts work or investigating bugs that may turn up in
low-level assembly code (assuming you're working in C).

I could go on and write a lot about the details involved in doing these
things.... but I'm going to hold off for now (and get back to work)
until someone shows some signs of actually needing some help.

I know things are stagnent right now.... over the last couple years I've
worked on this project on-and-off, and right now I'm dedicated to a
couple other non-website project, but eventually I'll be back on this
project for a while, as I have been many times before.  Maybe some other
people will also get involved in the meantime or when I get back into
it.  You can start hacking on the code anytime, and even if I'm busy
I'll always try to make time to help in those small but critical ways
like explaining how some part of the code or fpga works.



Paul

#1004 From: "Bernie Pallek" <bmatthiasp@...>
Date: Thu Jul 10, 2003 3:04 pm
Subject: Re: "Unlimited" file size, rewind, FF, etc support
bmatthiasp
Send Email Send Email
 
Okay, sounds good.  I'll start reading more of the code.

- bernie


--- In pjrcmp3dev@yahoogroups.com, Paul Stoffregen <Paul@P...> wrote:
> >
> >
> >I don't know whether or not someone is working on supporting
unlimited file size, rewind, fast forward, etc... Paul commented some
time ago about the plan for pre-caching the next several songs, which

[...]

> Bernie, to get the ball rolling, you'll really need to get into the
code
> and start hacking.  Like most open-source project, actual hacking
on the
> code is the only way to move things along.
>
> Even though I'm not currently dedicating time to this project, if
you or
> anyone else is making a serious attempt, I'll always find some bits
of
> time to help in small but important ways... like explaining how
some
> mysterious parts work or investigating bugs that may turn up in
> low-level assembly code (assuming you're working in C).

[...]

#1005 From: Laine Walker-Avina <nerdguy0@...>
Date: Thu Jul 10, 2003 9:31 pm
Subject: Re: "Unlimited" file size, rewind, FF, etc support
nerdguy0
Send Email Send Email
 
--- Paul Stoffregen <Paul@...> wrote:
> >I don't know whether or not someone is working on
> supporting unlimited file size, rewind, fast forward,
> etc... Paul commented some time ago about the plan for
> pre-caching the next several songs, which is related.
> Anyway, here are my thoughts, in case anyone is
> interested in implementing stuff (if it's not already
> underway):
> >
> I am currently not working on this mp3 player project.  I
> hope to get
> back into it later in the summer.
>
> All of these wish-list items seem simple in concept, but
> involve quite a
> bit of work on a lot of details.  For example, most of
> these involve
> predictions of data consumption rates which don't really
> exist in the
> code at this time, and are made more complex by the
> possibility of VBR
> encoded mp3 files.
>
> >- pre-cache the next 3 songs... 10 seconds each should
> be enough, but what if user changes playmode during
> pre-cache or before pre-cached data is used?  (does it
> invalidate the pre-cached data?)
> >
> >- the "current" song should be double-buffered, to allow
> unlimited file size playback, with "rewind" capability
> worked in by allowing playback routine to fetch small
> cached blocks in a reverse order (eg. the first 512 bytes
> of each 4K block or whatever); the buffers should use
> whatever free memory remains after accounting for FAT
> storage/play lists, pre-cached next songs, other scratch
> storage, etc
> >
> >- fast-forward can just skip blocks of memory, nothing
> too fancy
> >
> >- when skipping ahead to the next song, a
> quick-but-smooth volume fade would sound better than an
> abrupt stop -- HOWEVER... there are some mix CDs that
> make one track go directly into the next, so this
> fade-between tracks should be optional/configurable ..
> or, better yet, it can do the quick fade only if user
> presses "skip", but if the tracks proceed "naturally", no
> fade
> >
> >Well, I'm sure there's stuff I missed, but I just wanted
> to get the ball rolling (if it's not already).
> >
> Bernie, to get the ball rolling, you'll really need to
> get into the code
> and start hacking.  Like most open-source project, actual
> hacking on the
> code is the only way to move things along.
>
> Even though I'm not currently dedicating time to this
> project, if you or
> anyone else is making a serious attempt, I'll always find
> some bits of
> time to help in small but important ways... like
> explaining how some
> mysterious parts work or investigating bugs that may turn
> up in
> low-level assembly code (assuming you're working in C).
>
> I could go on and write a lot about the details involved
> in doing these
> things.... but I'm going to hold off for now (and get
> back to work)
> until someone shows some signs of actually needing some
> help.
>
> I know things are stagnent right now.... over the last
> couple years I've
> worked on this project on-and-off, and right now I'm
> dedicated to a
> couple other non-website project, but eventually I'll be
> back on this
> project for a while, as I have been many times before.
> Maybe some other
> people will also get involved in the meantime or when I
> get back into
> it.  You can start hacking on the code anytime, and even
> if I'm busy
> I'll always try to make time to help in those small but
> critical ways
> like explaining how some part of the code or fpga works.
>
> Paul

I have a question about file_uncache: for the offset
parameter, is it from the begining of the entire file or
just that in cache? Also, does file_cache(_work) do
anything special to the last block in cache when it runs
out of memory? A general overview of how the cache and
playing queue works as of now would be nice too.

Thanks,
Laine

=====
Laine Walker-Avina
    nerdguy0@...

In /dev/null, no one can hear your stream.

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

#1006 From: Laine Walker-Avina <nerdguy0@...>
Date: Fri Jul 11, 2003 1:31 am
Subject: Added Support for Files Bigger Than SIMM
nerdguy0
Send Email Send Email
 
I just committed the code to cvs, give it a try. Currently,
it swaps out the file in 2 meg increments in order to
support SIMMs as small as 4 megs. You can change this by
adjusting the OOM_SWAP_AMOUNT define in main.c if you have
a larger SIMM and don't want the disk to spin-up as
frequently.

Laine

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

#1007 From: "Bernie Pallek" <bmatthiasp@...>
Date: Fri Jul 11, 2003 4:26 pm
Subject: Re: Added Support for Files Bigger Than SIMM
bmatthiasp
Send Email Send Email
 
Excellent, I will definitely be trying this ASAP (tonight some time, probably). 
I appreciate your effort on this feature, as most of my MP3s are longish (5+
mins) and encoded at 192CBR or VBR.

Perhaps I can take a look at some of the tree-view problems (I noticed it only
seems to scroll down, and can get the cursor "lost" in some cases).  I only just
started using the tree-view 3 days ago (!!).

Thanks, Laine!  I'll let you know how it works on my end.

- bernie


--- In pjrcmp3dev@yahoogroups.com, Laine Walker-Avina <nerdguy0@y...> wrote:
> I just committed the code to cvs, give it a try. Currently,
> it swaps out the file in 2 meg increments in order to
> support SIMMs as small as 4 megs. You can change this by
> adjusting the OOM_SWAP_AMOUNT define in main.c if you have
> a larger SIMM and don't want the disk to spin-up as
> frequently.
>
> Laine
>
> __________________________________
> Do you Yahoo!?
> SBC Yahoo! DSL - Now only $29.95 per month!
> http://sbc.yahoo.com

#1008 From: Laine Walker-Avina <nerdguy0@...>
Date: Fri Jul 11, 2003 5:18 pm
Subject: Re: Re: Added Support for Files Bigger Than SIMM
nerdguy0
Send Email Send Email
 
--- Bernie Pallek <bmatthiasp@...> wrote:
> Excellent, I will definitely be trying this ASAP (tonight
> some time, probably).  I appreciate your effort on this
> feature, as most of my MP3s are longish (5+ mins) and
> encoded at 192CBR or VBR.
>
> Perhaps I can take a look at some of the tree-view
> problems (I noticed it only seems to scroll down, and can
> get the cursor "lost" in some cases).  I only just
> started using the tree-view 3 days ago (!!).
>
> Thanks, Laine!  I'll let you know how it works on my end.
>
> - bernie

The way the treedir code works now is a kludge I did so we
could have basic file browsing. I'm actually working a
rewrite of the treedir code so it can have a flat n-level
tree display like most computers. It still needs some
fleshing out before I commit it to CVS though. I'll try to
get it mostly done over the next couple of days(hopefully).

Laine

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

#1009 From: "Bernie Pallek" <bmatthiasp@...>
Date: Fri Jul 11, 2003 10:20 pm
Subject: Re: Added Support for Files Bigger Than SIMM
bmatthiasp
Send Email Send Email
 
Oh, okay!  Man, wherever I turn, you're one step ahead of me (this is
not a bad thing, however).

Is there anything not too difficult I could help with then?  Perhaps
getting the disk spin-up going a little bit (not a sophisticated
predict-time-based on statistics stuff yet)?

- bernie


--- In pjrcmp3dev@yahoogroups.com, Laine Walker-Avina <nerdguy0@y...>
wrote:
>
> --- Bernie Pallek <bmatthiasp@y...> wrote:
> > Excellent, I will definitely be trying this ASAP (tonight
> > some time, probably).  I appreciate your effort on this
> > feature, as most of my MP3s are longish (5+ mins) and
> > encoded at 192CBR or VBR.
> >
> > Perhaps I can take a look at some of the tree-view
> > problems (I noticed it only seems to scroll down, and can
> > get the cursor "lost" in some cases).  I only just
> > started using the tree-view 3 days ago (!!).
> >
> > Thanks, Laine!  I'll let you know how it works on my end.
> >
> > - bernie
>
> The way the treedir code works now is a kludge I did so we
> could have basic file browsing. I'm actually working a
> rewrite of the treedir code so it can have a flat n-level
> tree display like most computers. It still needs some
> fleshing out before I commit it to CVS though. I'll try to
> get it mostly done over the next couple of days(hopefully).
>
> Laine
>
> __________________________________
> Do you Yahoo!?
> SBC Yahoo! DSL - Now only $29.95 per month!
> http://sbc.yahoo.com

#1010 From: "Bernie Pallek" <bmatthiasp@...>
Date: Sat Jul 12, 2003 1:53 am
Subject: Re: Added Support for Files Bigger Than SIMM
bmatthiasp
Send Email Send Email
 
Okay, preliminary tests had bad, then good, results.  First time I
tried it on a ~68MB file, and the first time it tried to swap, it
spun up the drive, printed a lot of underscores (after "Found IDE
Master" message), but before it finished, (when it starts printing ",
Cylinders=0x3FFF, Heads...", it seemed to freeze for about 30
seconds, then it spewed a big blast of hi-ascii garbage, then another
pause, then another blast, then it rebooted.  Sorry, I didn't get a
log of it (hadn't started capturing), and also the speakers were not
connected, so I don't know what the audio output was when it messed
up.

Anyway, after restarting, I tried the same track (and it's playing
and trace-capturing at the moment), and it's 10:30 into the
128kbpsCBR track on an 8meg SIMM, and it has swapped about 5 times
without any problems.

I will keep logging it overnight...

-- Oops, I spoke too soon... it's currently going through and playing
the first little bit (1/10 sec...1 sec) of each track in sequence,
and then going to the next.

I will post the log in the files section, as I'm betting it's going
to be fairly large.

BTW, that "Duration is -1" thing looks suspicious...

- bernie


--- In pjrcmp3dev@yahoogroups.com, Laine Walker-Avina <nerdguy0@y...>
wrote:
> I just committed the code to cvs, give it a try. Currently,
> it swaps out the file in 2 meg increments in order to
> support SIMMs as small as 4 megs. You can change this by
> adjusting the OOM_SWAP_AMOUNT define in main.c if you have
> a larger SIMM and don't want the disk to spin-up as
> frequently.
>
> Laine
>
> __________________________________
> Do you Yahoo!?
> SBC Yahoo! DSL - Now only $29.95 per month!
> http://sbc.yahoo.com

#1011 From: Laine Walker-Avina <nerdguy0@...>
Date: Sat Jul 12, 2003 2:03 am
Subject: Re: Re: Added Support for Files Bigger Than SIMM
nerdguy0
Send Email Send Email
 
--- Bernie Pallek <bmatthiasp@...> wrote:
> Okay, preliminary tests had bad, then good, results.
> First time I
> tried it on a ~68MB file, and the first time it tried to
> swap, it
> spun up the drive, printed a lot of underscores (after
> "Found IDE
> Master" message), but before it finished, (when it starts
> printing ",
> Cylinders=0x3FFF, Heads...", it seemed to freeze for
> about 30
> seconds, then it spewed a big blast of hi-ascii garbage,
> then another
> pause, then another blast, then it rebooted.  Sorry, I
> didn't get a
> log of it (hadn't started capturing), and also the
> speakers were not
> connected, so I don't know what the audio output was when
> it messed
> up.
>
> Anyway, after restarting, I tried the same track (and
> it's playing
> and trace-capturing at the moment), and it's 10:30 into
> the
> 128kbpsCBR track on an 8meg SIMM, and it has swapped
> about 5 times
> without any problems.
>
> I will keep logging it overnight...
>
> -- Oops, I spoke too soon... it's currently going through
> and playing
> the first little bit (1/10 sec...1 sec) of each track in
> sequence,
> and then going to the next.
>
> I will post the log in the files section, as I'm betting
> it's going
> to be fairly large.
>
> BTW, that "Duration is -1" thing looks suspicious...
>
> - bernie
>

The "Duration is -1" just means that it will spin down the
HD right after it's done with it. When I was testing it, it
would mess up if it tried to uncache too soon. Some
preliminary questions:
How big is your SIMM?
How long does it take for your HD to spin-up?
Does it still mess up if you set the drive to never spin
down?

Laine

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

#1012 From: pjrcmp3dev@yahoogroups.com
Date: Sat Jul 12, 2003 2:07 am
Subject: New file uploaded to pjrcmp3dev
pjrcmp3dev@yahoogroups.com
Send Email Send Email
 
Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the pjrcmp3dev
group.

   File        : /debug_captures/buffer_swap_log.txt
   Uploaded by : bmatthiasp <bmatthiasp@...>
   Description : Laine added buffer swapping to support large files; here's a log
of it running with strange behaviour

You can access this file at the URL

http://groups.yahoo.com/group/pjrcmp3dev/files/debug_captures/buffer_swap_log.tx\
t

To learn more about file sharing for your group, please visit

http://help.yahoo.com/help/us/groups/files

Regards,

bmatthiasp <bmatthiasp@...>

#1013 From: "Bernie Pallek" <bmatthiasp@...>
Date: Sat Jul 12, 2003 2:13 am
Subject: Re: Added Support for Files Bigger Than SIMM
bmatthiasp
Send Email Send Email
 
Laine,

My SIMM is 8meg.

Regarding the "duration": ahhhh... I get it.

My disk spin down and up are set to "ASAP" (I guess it's the default
after uploading new firmware).  I've just changed the spin down
to "None".  I'm capturing again.

I forgot to mention in my last message, the ID3 fetcher is being
called each time we rebuffer.

- bernie


--- In pjrcmp3dev@yahoogroups.com, Laine Walker-Avina <nerdguy0@y...>
wrote:
>
> --- Bernie Pallek <bmatthiasp@y...> wrote:
> > Okay, preliminary tests had bad, then good, results.
> > First time I
> > tried it on a ~68MB file, and the first time it tried to
> > swap, it
> > spun up the drive, printed a lot of underscores (after
> > "Found IDE
> > Master" message), but before it finished, (when it starts
> > printing ",
> > Cylinders=0x3FFF, Heads...", it seemed to freeze for
> > about 30
> > seconds, then it spewed a big blast of hi-ascii garbage,
> > then another
> > pause, then another blast, then it rebooted.  Sorry, I
> > didn't get a
> > log of it (hadn't started capturing), and also the
> > speakers were not
> > connected, so I don't know what the audio output was when
> > it messed
> > up.
> >
> > Anyway, after restarting, I tried the same track (and
> > it's playing
> > and trace-capturing at the moment), and it's 10:30 into
> > the
> > 128kbpsCBR track on an 8meg SIMM, and it has swapped
> > about 5 times
> > without any problems.
> >
> > I will keep logging it overnight...
> >
> > -- Oops, I spoke too soon... it's currently going through
> > and playing
> > the first little bit (1/10 sec...1 sec) of each track in
> > sequence,
> > and then going to the next.
> >
> > I will post the log in the files section, as I'm betting
> > it's going
> > to be fairly large.
> >
> > BTW, that "Duration is -1" thing looks suspicious...
> >
> > - bernie
> >
>
> The "Duration is -1" just means that it will spin down the
> HD right after it's done with it. When I was testing it, it
> would mess up if it tried to uncache too soon. Some
> preliminary questions:
> How big is your SIMM?
> How long does it take for your HD to spin-up?
> Does it still mess up if you set the drive to never spin
> down?
>
> Laine
>
> __________________________________
> Do you Yahoo!?
> SBC Yahoo! DSL - Now only $29.95 per month!
> http://sbc.yahoo.com

#1014 From: Laine Walker-Avina <nerdguy0@...>
Date: Sat Jul 12, 2003 2:45 am
Subject: Re: Re: Added Support for Files Bigger Than SIMM
nerdguy0
Send Email Send Email
 
--- Bernie Pallek <bmatthiasp@...> wrote:
> Laine,
>
> My SIMM is 8meg.
>
> Regarding the "duration": ahhhh... I get it.
>
> My disk spin down and up are set to "ASAP" (I guess it's
> the default
> after uploading new firmware).  I've just changed the
> spin down
> to "None".  I'm capturing again.
>
> I forgot to mention in my last message, the ID3 fetcher
> is being
> called each time we rebuffer.
>
> - bernie

I fixed the id3 thing. I took a look at your log, and it
looks like the player didn't close the file correctly and
unallocate the buffer memory. So far I've only tried the
small files I had on the player with a 4 meg SIMM. I just
loaded some of my larger files on the HD and am in the
process of testing with the 4 meg SIMM. After it's done,
I'm going to try my 16 meg SIMM and see if it makes a
difference.

Laine

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

#1015 From: David Morrison <stupidrobothead@...>
Date: Mon Jul 14, 2003 3:43 pm
Subject: Max Size simm chip?
fdm225
Send Email Send Email
 
What is the max size simm that can be used?
 
dave

#1016 From: "Williams, Matt" <mwilliams@...>
Date: Mon Jul 14, 2003 3:43 pm
Subject: RE: Max Size simm chip?
ophbalance
Send Email Send Email
 
32 Meg.  This, I'm fairly sure, is listed on www.pjrc.com.
In fact, it's on the main page.  Quote "Memory, 4 to 32
Meg (72-Pin SIMM)".  Be forwarned that newer SIMMs are
not likely to work as well as older SIMMs due to a
change in the way they are spec'd.

Ophbalance
Matthew Williams

-----Original Message-----
From: David Morrison [mailto:stupidrobothead@...]
Sent: Monday, July 14, 2003 11:43 AM
To: pjrcmp3dev@yahoogroups.com
Subject: [pjrcmp3dev] Max Size simm chip?


What is the max size simm that can be used?

dave

#1017 From: "fdm225" <stupidrobothead@...>
Date: Mon Jul 14, 2003 4:17 pm
Subject: Sorry, I read the faq after asking.
fdm225
Send Email Send Email
 
--- In pjrcmp3dev@yahoogroups.com, David Morrison
<stupidrobothead@y...> wrote:
> What is the max size simm that can be used?
>
> dave

#1018 From: "duke_n0" <diesirae@...>
Date: Tue Jul 15, 2003 1:32 am
Subject: NTSC display?
duke_n0
Send Email Send Email
 
Greetings,
I have a 5.1" TFT (RCA) mounted in dash which I use for a variety of
things - GPS, laptop, TV-DVD etc. What I have in my car now is a
riped and striped old laptop with TV-out. It runs OSR2 striped,
winamp and ATI's remote wonder.
It works... but has many set-backs. The most prominate one is the
fish-eyed display of the laptop's ATI TV-out which I can't do
anything about. Having this player's info displayed through it would
be awesome.

#1019 From: "Bernie Pallek" <bmatthiasp@...>
Date: Tue Jul 15, 2003 2:19 am
Subject: Re: NTSC display?
bmatthiasp
Send Email Send Email
 
It wouldn't too too difficult to do what you want, I think.  You'd just need to
write a little program that can emulate the LCD display.  It would need serial
I/O, and some basic output functionality.  In fact, there might already be such
a program for windows somewhere in the files section or something.  Check there
for a start...

Can you write windows apps?  (VB or C++?)

- bernie


--- In pjrcmp3dev@yahoogroups.com, "duke_n0" <diesirae@c...> wrote:
> Greetings,
> I have a 5.1" TFT (RCA) mounted in dash which I use for a variety of
> things - GPS, laptop, TV-DVD etc. What I have in my car now is a
> riped and striped old laptop with TV-out. It runs OSR2 striped,
> winamp and ATI's remote wonder.
> It works... but has many set-backs. The most prominate one is the
> fish-eyed display of the laptop's ATI TV-out which I can't do
> anything about. Having this player's info displayed through it would
> be awesome.

#1020 From: "Bernie Pallek" <bmatthiasp@...>
Date: Tue Jul 15, 2003 7:01 am
Subject: Re: NTSC display?
bmatthiasp
Send Email Send Email
 
Hi again, here are a few more things to get you started...

A link to the LCD protocol:
http://www.pjrc.com/tech/mp3/lcd_protocol.html

A link to something I described that has already been done by Scott Tisdale
(link is from the protocol page):
http://www.pjrc.com/tech/mp3/sideprojects/jw002_protocol_vb.zip

Perhaps you can adapt Scott's program to your needs.  Write to me via email
(bmatthiasp at yahoo dot com) if you need some help.

- bernie

--- In pjrcmp3dev@yahoogroups.com, "duke_n0" <diesirae@c...> wrote:
> Greetings,
> I have a 5.1" TFT (RCA) mounted in dash which I use for a variety of
> things - GPS, laptop, TV-DVD etc. What I have in my car now is a
> riped and striped old laptop with TV-out. It runs OSR2 striped,
> winamp and ATI's remote wonder.
> It works... but has many set-backs. The most prominate one is the
> fish-eyed display of the laptop's ATI TV-out which I can't do
> anything about. Having this player's info displayed through it would
> be awesome.

#1021 From: "duke_n0" <diesirae@...>
Date: Wed Jul 16, 2003 12:02 am
Subject: Re: NTSC display?
duke_n0
Send Email Send Email
 
Well.. the idea was to get rid of the in-car PC all together.
I can code C++ though it takes me forever and a day.
In essence, I'm looking to make a TV-out for the player ;)
I'll never come to fruit.. at least not by me but hey..
what else have I got to do ....

--- In pjrcmp3dev@yahoogroups.com, "Bernie Pallek" <bmatthiasp@y...>
wrote:
> It wouldn't too too difficult to do what you want, I think.  You'd
just need to write a little program that can emulate the LCD
display.  It would need serial I/O, and some basic output
functionality.  In fact, there might already be such a program for
windows somewhere in the files section or something.  Check there for
a start...
>
> Can you write windows apps?  (VB or C++?)
>
> - bernie

Messages 992 - 1021 of 1369   Oldest  |  < Older  |  Newer >  |  Newest
Add to My Yahoo!      XML What's This?

Copyright © 2010 Yahoo! Inc. All rights reserved.
Privacy Policy - Terms of Service - Guidelines NEW - Help