On Mon, Aug 17, 2009 at 1:49 AM, Paul Louden wrote:
>
> Wouldn't that way be "test compile it for targets where IRAM might be a
> problem before trying to have it committed?" The whole red/green build thing
> is for when you miss something, not really so much for when you already know
> there's lik
On 17.08.2009, Rafael Carre wrote:
> If you fear your commit would break some platform, you
> could try:
> - coldfire (h120)
> - sh1 (the player is hwcodec and the others swcodec)
*All* SH1 targets are hwcodec (and are thus irrelevant when
testing DSP stuff). The difference between the Player an
> Would a single, say 32k, buffer be sufficient for all possible DSP without
> needing enable setting?
Yes - assuming you can gain that 32k back from somewhere else! ;-)
More seriously I don't know if the same buffer could be used for both
timestretch and other DSP purposes - I suspect not.
I
pondlife schrieb:
Timestretch uses several buffers (totalling about 28k), but none of them are
used for the input data. Also they are only allocated when the feature is
explicitly enabled, so as not to waste RAM for people who don't want to use
the feature. The downside is that an explicit "en
>> Ah, so this DSP effect is the only requiring a large buffer? Then OK. But
>> wait... What about time stretch? I think it also uses some kind of
>> buffer.
>>
> That I don't know. Time stretch was being developed concurrently so it
> might have come up with its own solution. It could also be
On Mon, 17 Aug 2009 17:28:06 +0100, roo...@blueyonder.co.uk wrote:
>Anyway, I'll try the patch when I find the time...
I had a go but to be honest I couldn't hear a difference when I tried
the following:
- listen to a transition loud jingle -> speech
- up limiter preamp by 8db
- reduce volume by
Al Le wrote:
On 17.08.2009 19:40, Jeff Goode wrote:
Al Le wrote:
why not have a large enough buffer that would be used by all DSP
effects?
Most DSP functions get along well enough without having their input
buffered anyway, so it wouldn't come up very often.
Ah, so this DSP effect is the o
Rafael Carre schrieb:
Le Mon, 17 Aug 2009 10:24:16 -0400,
Jeff Goode a écrit :
I don't know which targets are likely to fail. And the fact is that
I can't go compiling for each of a few dozen targets. I just don't
have the time for that. Do you have suggestions?
If you fear your c
Rafael Carre wrote:
Le Mon, 17 Aug 2009 10:24:16 -0400,
Jeff Goode a écrit :
I don't know which targets are likely to fail. And the fact is that
I can't go compiling for each of a few dozen targets. I just don't
have the time for that. Do you have suggestions?
If you fear your com
Le Mon, 17 Aug 2009 10:24:16 -0400,
Jeff Goode a écrit :
> I don't know which targets are likely to fail. And the fact is that
> I can't go compiling for each of a few dozen targets. I just don't
> have the time for that. Do you have suggestions?
If you fear your commit would break some platf
On 17.08.2009 19:40, Jeff Goode wrote:
Al Le wrote:
why not have a large enough buffer that would
be used by all DSP effects?
Most DSP functions get along well enough
without having their input buffered anyway, so it wouldn't come up very
often.
Ah, so this DSP effect is the only requiring
Al Le wrote:
On 17.08.2009 16:52, Jeff Goode wrote:
The 7k is mostly buffers and the code itself, which is whittled down
pretty far already. There's not a lot of fat in there.
Hm... I have a question: why not have a large enough buffer that would
be used by all DSP effects? IIUC, as of now
On 17.08.2009 16:52, Jeff Goode wrote:
The 7k is mostly buffers and the code itself, which is whittled down
pretty far already. There's not a lot of fat in there.
Hm... I have a question: why not have a large enough buffer that would
be used by all DSP effects? IIUC, as of now every DSP effe
On Mon, 17 Aug 2009 11:42:29 -0400, Jeff Goode
wrote:
>Can you use DSP's when listening to the radio? For instance, can you
>use the equalizer on it? If so, then yes, it should work. I've never
>looked into the radio function so I can't say for sure.
Sorry, I wasn't clear here. I have them
roo...@blueyonder.co.uk wrote:
On Mon, 17 Aug 2009 10:36:16 -0400, Jeff Goode
wrote:
I envisioned a use for listening to dynamic material in noisy
environments,
I listen to radio shows that are mainly speech. When on the train I
have to crank up the volume to be able to understand wh
On Mon, 17 Aug 2009 10:36:16 -0400, Jeff Goode
wrote:
>I envisioned a use for listening to dynamic material in noisy
>environments,
I listen to radio shows that are mainly speech. When on the train I
have to crank up the volume to be able to understand what is beeing
said. However a radio jingl
pondlife wrote:
IMHO, it would be useful, but 7k sounds a bit OTT..
Does set_limiter_buffer() need to be inlined?
pondlife
It doesn't *have* to be inlined, but it's only called once so it really
does make sense. I suppose I could rewrite it so that it's all one long
procedure. But it r
Thomas Martitz wrote:
It's basically replaygain with clipping prevention, with the
differences that only the passages that are too lout is scaled down by
a few dB, not the whole file...IIUC
I don't really see a sense in the feature, but I'm not opposed either.
This isn't a reimplementation of
Al Le wrote:
Jeff, I read the patch description and tried to understand what it
does but couldn't fully do it. (Disclaimer: I'm not a sound processing
expert.) And I'm sorry for not having replied earlier.
What I understood from reading the description is that it would have
an effect as if
Paul Louden wrote:
Nobody appears to have an opinion one way or the other regarding this
patch, so I plan to commit it tomorrow (Monday) and see how it
behaves during the build. We're going to see a red delta for bin
size and RAM (bloat o meter reports about 7000 bytes)
Is this really wor
IMHO, it would be useful, but 7k sounds a bit OTT..
Does set_limiter_buffer() need to be inlined?
pondlife
Al Le schrieb:
On 17.08.2009 07:44, Jeff Goode wrote:
Jeff Goode wrote:
The latest version of my limiter DSP was just posted this
afternoon. Its purpose is to amplify the signal by a user
selectable amount, then smoothly reduce gain for those samples that
clip as a result. This allows liste
On 17.08.2009 07:44, Jeff Goode wrote:
Jeff Goode wrote:
The latest version of my limiter DSP was just posted this afternoon.
Its purpose is to amplify the signal by a user selectable amount, then
smoothly reduce gain for those samples that clip as a result. This
allows listening to dynamic
Nobody appears to have an opinion one way or the other regarding this
patch, so I plan to commit it tomorrow (Monday) and see how it behaves
during the build. We're going to see a red delta for bin size and RAM
(bloat o meter reports about 7000 bytes)
Is this really worth 7k? It's not even
Jeff Goode wrote:
The latest version of my limiter DSP was just posted this afternoon.
Its purpose is to amplify the signal by a user selectable amount, then
smoothly reduce gain for those samples that clip as a result. This
allows listening to dynamic material in noisy environments that coul
Hi guys,
The latest version of my limiter DSP was just posted this afternoon.
Its purpose is to amplify the signal by a user selectable amount, then
smoothly reduce gain for those samples that clip as a result. This
allows listening to dynamic material in noisy environments that could
drown
Please do. There's been a report from a h140 user of choppy audio and
constant disk spinning. It works fine on my flash based player (Sansa
E280), though. I suspect that for some reason he's getting buffer
underruns though I don't know what might be causing those. Any ideas?
Jeff
David J
This sounds like a great feature -- one I've wanted for quite a while.
I haven't tried it out yet but I'll be interested to hear how it
sounds.
-David
Dan Everton wrote:
How does this compare to just adding ReplayGain tags to your files?
IIRC, the ReplayGain code currently supports both a pre-amp and an
"avoid clipping" setting.
The "avoid clipping" setting for ReplayGain is completely different. It
looks at the stored peak value. If that i
Replaygain doesn't reduce dynamic range, which is the goal of a
limiter. The idea is to amplify low level material so it's audible in a
noisy environment and at the same time avoid clipping your amps.
Replaygain tags, even with preamping and avoid clipping, will bring the
entire waveform up t
On Tue, 14 Jul 2009 12:22 -0700, "Jonathan Gordon"
wrote:
> 2009/7/14 Dan Everton :
> >> Summing up: this patch adds a "Limiter Preamp" menu item to the sound
> >> settings menu on SWCODEC targets. Any selection above 0db amplifies the
> >
> > How does this compare to just adding ReplayGain tags
2009/7/14 Dan Everton :
>> Summing up: this patch adds a "Limiter Preamp" menu item to the sound
>> settings menu on SWCODEC targets. Any selection above 0db amplifies the
>
> How does this compare to just adding ReplayGain tags to your files?
> IIRC, the ReplayGain code currently supports both a
> Summing up: this patch adds a "Limiter Preamp" menu item to the sound
> settings menu on SWCODEC targets. Any selection above 0db amplifies the
How does this compare to just adding ReplayGain tags to your files?
IIRC, the ReplayGain code currently supports both a pre-amp and an
"avoid clippin
Hi all,
I've put a lot of work into this patch and it's ready for review. I
sure would appreciate it if one of the devs could look it over for
inclusion.
Summing up: this patch adds a "Limiter Preamp" menu item to the sound
settings menu on SWCODEC targets. Any selection above 0db amplifie
Hi,
I finally have a functional limiter DSP feature. As noted in FlySpray,
it does work, but it needs tweaking. It's currently set up to reduce
gain in .6 dB steps, which in my opinion is too coarse. Finer steps are
certainly possible, at the expense of compute time for each sample. This
cou
35 matches
Mail list logo
