Re: pcm_set_frequency is ignored
2008/8/31 Joseph Garvin <[EMAIL PROTECTED]>: > On Sun, Aug 31, 2008 at 3:05 AM, Magnus Holmgren <[EMAIL PROTECTED]> wrote: >> >> Joseph Garvin wrote: >> >>> To shrink my plugin size I'm trying to convert my sound samples to be >>> 22050hz instead of 44100. But when I do this the sound always plays too fast >>> like a chipmunk. I'm calling pcm_set_frequency(22050) but no matter what >>> number I give it (I tested crazy values like 100) I get the same result. It >>> always tries to play at 44100hz. I'm trying on the Sansa e200 simulator. Is >>> this a limitation of the simulator or maybe of the e200? If so it'd be nice >>> to get some sort of console warning. >> >> pcm_set_frequency sets the frequency of the hardware, but it is usually >> quite limited in what frequencies it supports. Try dsp_configure, using >> DSP_SWITCH_FREQUENCY, to set the frequency. See the mpegplayer audio thread >> for an example. > > I tried: > > struct dsp_config* dsp = (struct dsp_config *)rb->dsp_configure(NULL, > DSP_MYDSP, > > CODEC_IDX_AUDIO); > rb->dsp_configure(dsp, DSP_SWITCH_FREQUENCY, 22050); > rb->pcm_set_frequency(22050); > rb->pcm_apply_settings(); > > But this still had no effect, at least in the simulator. Do I need to use > dsp_process somehow? It's unclear to me how it works. I'm still playing the > sound with pcm_play_data. > The uisimulator is not using rockboxs dsp yet, I have here some basic code to use the dsp for bass, treble settings. The frequency stuff is on todo for the audioapi. Maybe I will find some time to commit some stuff during the coming week. -- BSc, Christian Gmeiner
Question about audiohw_set_xxx_vol
Hi all, as the term at university is over I have some time to work more on sound.c and affected files :) At the moment I am looking at set_prescaled_volume in sound.c... the big ifdef suff at the end of this method. #if CONFIG_CODEC == MAS3507D dac_volume(tenthdb2reg(l), tenthdb2reg(r), false); #elif defined(HAVE_UDA1380) || defined(HAVE_WM8975) || defined(HAVE_WM8758) \ || defined(HAVE_WM8731) || defined(HAVE_WM8721) || defined(HAVE_WM8751) \ || defined(HAVE_AS3514) || defined(HAVE_TSC2100) audiohw_set_master_vol(tenthdb2master(l), tenthdb2master(r)); #if defined(HAVE_WM8975) || defined(HAVE_WM8758) \ || (defined(HAVE_WM8751) && !defined(MROBE_100)) \ || defined(HAVE_TSC2100) || defined(HAVE_WM8985) audiohw_set_lineout_vol(tenthdb2master(0), tenthdb2master(0)); #endif #elif defined(HAVE_TLV320) || defined(HAVE_WM8978) || defined(HAVE_WM8985) audiohw_set_headphone_vol(tenthdb2master(l), tenthdb2master(r)); #endif My goal is it to get rid of it... but there are - I think - two ways to do it. 1) Introduce an #define in each audio driver header... something like #define audiohw_set_volume(l, r) audiohw_set_master_vol(tenthdb2master(l), tenthdb2master(r)) Then I would use audiohw_set_volume in sound.c 2) Extend the current audiohw api with methods like void audiohw_set_master_vol(int l, int r) void audiohw_set_lineout_vol(int l, int r) and use master for setting volume for headphones and lineout for changing vol at lineout. BUT as far as I can see lineout is not used in rockbox at the moment (called from /apps )... hmmm How do we want to handle lineout? Do we really need it? I would go for 2), as it seems for me the cleanest solution. thanks, Christian
Some questions about naming of some functions
HI all,
as I have more time for rockbox now (term at university is over and I have
some holidays), I want to finish my started work of "audio hardware
unification".
The goal of my work should be to clean up firmware/sound.c and minimize the
usage of #if defined(...). At the moment I am looking at the volume
functions
with their different names and different usages.
Lets start :)
- firmware/sound.c -
static void set_prescaled_volume(void)
{
int prescale = 0;
int l, r;
/* The WM codecs listed don't have suitable prescaler functionality, so we
let
* the prescaler stay at 0 for these unless SW tone controls are in use */
#if defined(HAVE_SW_TONE_CONTROLS) || !(defined(HAVE_WM8975) \
|| defined(HAVE_WM8731) || defined(HAVE_WM8721) || defined(HAVE_WM8751)
\
|| defined(HAVE_WM8758))
prescale = MAX(current_bass, current_treble);
if (prescale < 0)
prescale = 0; /* no need to prescale if we don't boost
bass or treble */
/* Gain up the analog volume to compensate the prescale gain reduction,
* but if this would push the volume over the top, reduce prescaling
* instead (might cause clipping). */
if (current_volume + prescale > VOLUME_MAX)
prescale = VOLUME_MAX - current_volume;
#endif
#if defined(HAVE_SW_TONE_CONTROLS)
dsp_callback(DSP_CALLBACK_SET_PRESCALE, prescale);
#elif CONFIG_CODEC == MAS3507D
mas_writereg(MAS_REG_KPRESCALE, prescale_table[prescale/10]);
#elif defined(HAVE_UDA1380)
audiohw_set_mixer_vol(tenthdb2mixer(-prescale),
tenthdb2mixer(-prescale));
#endif
if (current_volume == VOLUME_MIN)
prescale = 0; /* Make sure the chip gets muted at VOLUME_MIN */
l = r = current_volume + prescale;
if (current_balance > 0)
{
l -= current_balance;
if (l < VOLUME_MIN)
l = VOLUME_MIN;
}
if (current_balance < 0)
{
r += current_balance;
if (r < VOLUME_MIN)
r = VOLUME_MIN;
}
#if CONFIG_CODEC == MAS3507D
dac_volume(tenthdb2reg(l), tenthdb2reg(r), false);
#elif defined(HAVE_UDA1380) || defined(HAVE_WM8975) || defined(HAVE_WM8758)
\
|| defined(HAVE_WM8731) || defined(HAVE_WM8721) || defined(HAVE_WM8751) \
|| defined(HAVE_AS3514)
audiohw_set_master_vol(tenthdb2master(l), tenthdb2master(r));
#if defined(HAVE_WM8975) || defined(HAVE_WM8758) \
|| (defined(HAVE_WM8751) && !defined(MROBE_100))
audiohw_set_lineout_vol(tenthdb2master(0), tenthdb2master(0));
#endif
#elif defined(HAVE_TLV320)
audiohw_set_headphone_vol(tenthdb2master(l), tenthdb2master(r));
#endif
}
#endif /* (CONFIG_CODEC == MAS3507D) || defined HAVE_UDA1380 */
Lets discuss used functions and why they are used in this context. Before I
start... I must admit that I do not know what prescaling means in the
context
of audio - maybe somebody can help me here out.
The first part of this function sets the prescale value.
uda1380:
audiohw_set_mixer_vol(tenthdb2mixer(-prescale),
tenthdb2mixer(-prescale));
As I do not know what prescaling means it seems that we need to change
the mixer value
of the uda1380 chip... why don't we need this on the other chips?
Can we rename this part to audiohw_set_prescaler?
The second part changes the real volume the the output which we can hear
through our headphones.
Here we have three variations:
* audiohw_set_master_vol
* audiohw_set_lineout_vol
* audiohw_set_headphone_vol
which do the same... setting volume for our headphones. The question for me
is now, if we need all these different functions, which
have the same result in the end? Is it important for the caller of such a
function to know what technique we use to change volume (set headphone
registers,
set master volume registers, set lineout registers)?
I think no! As a result of this we could have one unique function name, e.g.
audiohw_set_volume(l, r) to change the volume.
Please tell me about your opinions and maybe you can give me an
understandable url/document, which explains what prescale does.
Thanks,
Christian
Re: christian: r15632 - in trunk/firmware: . export
2007/11/16, Linus Nielsen Feltzing <[EMAIL PROTECTED]>:
> [EMAIL PROTECTED] wrote:
> > Modified: trunk/firmware/export/mas35xx.h
> > ===
> > --- trunk/firmware/export/mas35xx.h 2007-11-15 21:20:29 UTC (rev 15631)
> > +++ trunk/firmware/export/mas35xx.h 2007-11-15 23:32:56 UTC (rev 15632)
> > @@ -22,4 +22,98 @@
> > #ifndef _MAS35XX_H
> > #define _MAS35XX_H
> >
> > +#include "config.h"
> > +
> > +#if CONFIG_CODEC == MAS3507D
> > +static const unsigned int bass_table[] =
> > +{
>
> Ehum. I'm not sure I like to have header files that declare static
> constant data. The same data will be instantiated in every file that
> includes this header file, and that is certainly a waste of memory.
>
> I'ts possible that the compiler/linker can see that the data isn't used
> and remove it, but I still consider it very bad practice.
I will fix this in of my next commits. Atm i am working to get a
general interface for audiohw for software and hardware based players.
Before I will commit my work on this part, I will update the wiki page
and the corresponding patch id in tracker, so that everybody can
review and commit it.
Btw, it seems that the compiler is intellegent enough to fix this
issue when i am looking at
http://build.rockbox.org/cvsmod/sizes-20071115T233352Z
Greets, Christian
Re: christian: r13620 - in trunk/firmware: drivers/audio export
2007/6/12, Dave Chapman <[EMAIL PROTECTED]>: [EMAIL PROTECTED] wrote: > Modified: trunk/firmware/drivers/audio/tlv320.c > === > --- trunk/firmware/drivers/audio/tlv320.c 2007-06-11 13:32:29 UTC (rev 13619) > +++ trunk/firmware/drivers/audio/tlv320.c 2007-06-11 23:39:07 UTC (rev 13620) > @@ -219,10 +219,10 @@ > } > > /** > - * Mute (mute=true) or enable sound (mute=false) > + * Mute (mute=1) or enable sound (mute=0) > * > */ > -void audiohw_mute(bool mute) > +void audiohw_mute(int mute) Was there a reason for making this parameter an int in all drivers, rather than bool? I realise that only the tlv320 driver used bool before your commit, but that would seem clearer IMO. I have choosen an int, because more driver used and int before my changes, but it is also no problem to change it to a bool version. Will do the change in my next commit - today or tomorrow. Greets, Christian
Re: pitchscreen on the sansa?
2007/5/28, Jonathan Gordon <[EMAIL PROTECTED]>: hey all, came up in IRC that the pitch screen isnt enabled on the sansa, does anyone know why? I did a quick test compile and apart from the wheel not being used in the screen it works fine. Dont know why, but maybe it was forgotten to enable... so.. enable it :)
Re: Sansa radio driver (AS5314 help
Maybe there could also be some extra work to do - something like 7084 |= 1 - to get better audio results. I have played a lot with volume settings and i dont get it better as it is yet. 2007/5/16, Michael Sevakis <[EMAIL PROTECTED]>: This brings up some important questions to answer: What audio processing/switching hardware exists outside the codec chip (besides this)? Is it an established fact that the OF eq is software? Signal processing could easily be slipped in on the I2S bus between the CPU and AS3514. I noticed also location 7020 is always checked after reading TIMER1_VAL once in the OF menu. Value is always 0x4000 at least to the point I've gone so far. - Original Message - From: "Ivan Zupan" <[EMAIL PROTECTED]> To: "Rockbox development" Sent: Wednesday, May 16, 2007 5:26 PM Subject: Re: Sansa radio driver (AS5314 help > Great news folks. Very loud audio! > The secret was the stuff involving address 0x7084 and 0x7080! > Now to work on the algorithms for tuning and getting volume control to > work with the line1 in (very loud even if gain is very low) > Btw, the settings below actually mute line1 in while tuning, so it is a > bit misleading :) > Thanks for the help with figuring this out. > > > > Antonius Hellmann wrote: > > If you can hear any sound, then I would assume, that the device is > > working. > > So nothing more to be done with the radio init/powerup. > > I bet, that the audio configuration is not correct yet. > > In the emu I found following AS3514 init sequence after entering the > > radio menu > > and after setting up the tuner: > > AUDIOSET1 4e > > 7084 |= 1 < don't know, wether this is radio related > > 7080 |= 4 < don't know, wether this is radio related > > HPH_OUT_L e0 > > HPH_OUT_L 6b > > HPH_OUT_R eb > > LINE_IN1_L df > > LINE_IN1_R df > > AUDIOSET1 4a > > AUDIOSET1 4e > > LINE_IN1_L df > > LINE_IN1_R df > > > > And regarding your other question: > > 69ddd55 e8f4 CPU 7020 R4-4000 > > 69ddd57 e8fc CPU 7020 W4-4000 > > I added the comment after looking at the assembler code at addr e8f4. > > The cpu reads a value from 0x7020, bics bit11 and stores the > > result. Nothing wrong here. >
Please review and ...
... comment AudioHardwareAPIProposal http://www.rockbox.org/twiki/bin/view/Main/AudioHardwareAPIProposal Thanks, Christian
Re: Sansa radio driver (AS5314 help)
Hi Ivan... I have committed some changes to as3514 driver to enable lineIn 1 and set some default gain. Lets hope FM chip is connected to LineIn1 else we could try LineIn 2. Please keep me up2date... greets, Christian 2007/5/13, Christian Gmeiner <[EMAIL PROTECTED]>: Hi Ivan.. can we meet us in irc... I will hang around for the next 2-3 hours there. My nick is austriancoder. It should be a work of 10-15 minutes. Or I can modify the driver to enable lines and micros and you can check which is needed. I have only a Sansa without radio :( See you there 2007/5/13, Ivan Zupan <[EMAIL PROTECTED]>: > Hi all, > > I am working on a Sansa radio driver. So far, I have implemented the > basics for the LV24020LP chip, and have been able to tune and measure > signal strength. However, I need some help with getting the AS5314 chip > to enable line in (or mic in depending on how they connect the radio). > Since the AS chip is covered by an NDA of sorts, I need someone who > signed it to update the driver so that we can get these two sources to > "mix" (or just channel one of them) to the headphone jack. > > TIA, > Ivan > >
Re: Sansa radio driver (AS5314 help)
Hi Ivan.. can we meet us in irc... I will hang around for the next 2-3 hours there. My nick is austriancoder. It should be a work of 10-15 minutes. Or I can modify the driver to enable lines and micros and you can check which is needed. I have only a Sansa without radio :( See you there 2007/5/13, Ivan Zupan <[EMAIL PROTECTED]>: Hi all, I am working on a Sansa radio driver. So far, I have implemented the basics for the LV24020LP chip, and have been able to tune and measure signal strength. However, I need some help with getting the AS5314 chip to enable line in (or mic in depending on how they connect the radio). Since the AS chip is covered by an NDA of sorts, I need someone who signed it to update the driver so that we can get these two sources to "mix" (or just channel one of them) to the headphone jack. TIA, Ivan
Re: Improving simulator
2007/5/10, Jonathan Gordon <[EMAIL PROTECTED]>: as has been said, the vast majority of #ifdef SIMULATOR is in apps/ so moving to a target-tree sort of system wouldnt make sense... Have a look at this: [EMAIL PROTECTED] ~/rockbox $ find apps/ | xargs grep 'SIMULATOR' | wc -l 694 [EMAIL PROTECTED] ~/rockbox $ find firmware/ | xargs grep 'SIMULATOR' | wc -l 640
Re: Improving simulator
2007/5/10, RaeNye <[EMAIL PROTECTED]>: I agree with the general idea, but I see a problem with allowing the simulator to be configured for different platforms. We need to configure lcd size & depth, RTC availability, available buttons and keymaps, remote lcd and buttons if applicable, etc. These are not questions I'd like to answer while running tools/configure (maybe the lcd size is ok, but buttons?) so there has to be a way to make it read some code off the relevant target tree. To create the config-sdl, we can use the informations from the choosen target conf-xxx. So we can have a stub config-sdl, which we fill with target specific informations. config-x5 | \/ ready to use config-sdl -> compile rockbox /\ | config-sdl stub
Re: Improving simulator
2007/5/10, Linus Nielsen Feltzing <[EMAIL PROTECTED]>: Christian Gmeiner wrote: > To run the new created rockbox.x86 we need a special boot loader, > which loads compiled code form x86 and executes it. Why would we need that? Hmm... good question ;) If I recheck it in my head then it will work without the bootloader. We create a normal executable and run it.
Re: Improving simulator
2007/5/10, Dave Chapman <[EMAIL PROTECTED]>: Christian Gmeiner wrote: > The big plus point is that we dont need to care about the simulator > with #ifdef's anymore as the simulator is a normal target. I don't see how that will happen - won't it just mean replacing "#ifdef SIMULATOR" with "#ifdef SDL_TARGET" ? No you are wrong.. we will use the target tree feature: firmware/target/sdl/* Here we implement, for instance, a lcd driver based on sdl, audio driver based on sdl,... Looking at the current code, there seem to be a lot of #ifdef SIMULATOR checks which are not needed - e.g. lines of the form: #if defined(CPU_COLDFIRE) && !defined(SIMULATOR) can just be changed to: #ifdef CPU_COLDFIRE - the CONFIG_CPU macro in the config files aren't defined for the simulator. Another problem is simply hardware features of targets which are not implemented in the sim - mainly the MAS on Archos devices, radio, recording, plus various other things like HAVE_PWM_BACKLIGHT_FADING. How would your proposal deal with these? I dont want to write an emulator, I want to integrate the simulator better into the current source! These are two _very_ different things. So... whren we build a simulator for target X5, we will get a sdl based executable (in combination with the bootloader), which has the same size of lcd as x5, has the same buttons as x5, has recording if supported - like our current uisimulator. We can run now rockbox on our pc with sdl.. we will use sdl to play sound and so on. But you have now the same core (threading,..) as we would compile rockbox for a target, which can help debugging. I'm not convinced that a radical change in architecture is needed - the time might be better spent just implementing more features in the current sim, and ensuring #ifdef SIMULATOR is only being used when it absolutely has to be. Believe me that nobody wants to check, if this ifdef is okay or not... its much easier when there are none or a very small amout of these #ifdef SIMULATOR. Christian
Re: Improving simulator
2007/5/10, Linus Nielsen Feltzing <[EMAIL PROTECTED]>: Christian Gmeiner wrote: > But I am not a build system guru.. so somebody need to help out, if my > idea of a simulator is wanted and accepted by the community and the > developers. One major hassle with simulator builds are the plugins, and I don't see how a separate x86 target could help that. By the way, X86 is a bad target name, since the sim can run on Mac OSX with PowerPC, can't it? The name is not good.. so rename it to target sdl
Re: Improving simulator
Hi Steve, 2007/5/10, pondlife <[EMAIL PROTECTED]>: Hi Christian, I agree with the principle. As well as device support, the simulator currently uses some other separate kernel code (all the multi-threading for example). I would particularly hope that such a simulator could be used to debug some of the more subtle issues (race conditions etc.) which it currently often fails to reproduce at all. Such a simulator would still need to offer an emulation of different targets' hardware - in particular display capabilities (sizes, colours, and the Archos Player's charcell display) and buttons. For this step we need to modify tools/configure. * select wanted target * select simulator * buildsystem needs now to generate a config-x86 on-the-fly based on config-xxx of selected target. But I am not a build system guru.. so somebody need to help out, if my idea of a simulator is wanted and accepted by the community and the developers. Greets, Christian
Improving simulator
Hi all. I know the sources of rockbox for a long time and I think its time for a revolution :) Maybe you all know the #ifdef SIMULATOR stuff all over the source... and we could get rid of them with some work. My idea is to create a new target called x86 where we write audio/lcd/ata/threading drivers based on sdl and normal *nix. If a user/developer selects now in tools/configure his player and then Simulator the build system should generate a firmware/export/config-x86 based on the selected target (screen size, recording, remote control, ...) and then should start compiling a rockbox.x86, plugins and other stuff. To run the new created rockbox.x86 we need a special boot loader, which loads compiled code form x86 and executes it. something like # bootloader rockbox.x86 Starting RockBox simulator for target XY... The big plus point is that we dont need to care about the simulator with #ifdef's anymore as the simulator is a normal target. What do you think about my idea? Thanks, austriancoder
Re: Google's Summer of Code
Hi friends,
Between March 5 - 12, 2007 we can apply to become a menthoring organization
for Google's Summer of Code 2007. ("The organization should choose a single
administrator to submit its application via the GSoC web app between March
5-12, 2007.")
For this to be a viable option we need to cough up a list of interesting
projects as well as a list of volunteering mentors (individuals).
I think the best place for this is the wiki.
greets,
Christian
PS: I am interesed doing a soc project..
Cooperation with Austriamicrosystems
Read more about this topic here: http://www.rockbox.org/twiki/bin/view/Main/Austriamicrosystems Greets, austriancoder
