Hello!
I have recently made some updates to many drivers, among other things to minimize clicks and pops. And as it happens, I have just today released those updates in the last message of this thread:
viewtopic.php?f=13&t=680
Could you verify whether this driver still gives you the clicks?
Also, could you verify how your audio data is scaled? It should be (normal) signed 16-bit numbers. Minimum is 0x8000 = -32768, 0xFFFF = -1, 0x0000 = 0, 0x0001 = 1, and maximum is 0x7FFF = 32767.
If clicks continue, could you upload one (short) example of the audio snippets you are playing back? It can be in the same raw data format as it is in the file, I can handle it.
Just as a side comment: you should not need to manually switch the DAOSET_CF register. Just verify that the last stereo word you write to the driver contains zeros for both the left and right channel and there should be no clicks.
Kind regards,
- Henrik
New Audio Driver Collection
Re: New Audio Driver Collection
Good signatures never die. They just fade away.
Re: New Audio Driver Collection
Hello,
I have some difficulties using the AuOutput driver. I need to permanently set the volume level to some value. When I run the driver from shell, it works as expected (for example "AUOUTPUT -v -l-10" sets the volume to -10dB). But it does not work using the config.txt, which would be ideal. Using the verbose output, it does report the volume is set to -10dB, but it does not really change the volume level.
I tried it with and without the RUN command, result is always the same.
My current configuration looks like this:
Terminal log shows this:
But running the auoutput report (the output level really is the 0dB):
Same command from terminal instead of config.txt, this way it does change the volume output level:
Any suggestions are welcome.
Martin.
I have some difficulties using the AuOutput driver. I need to permanently set the volume level to some value. When I run the driver from shell, it works as expected (for example "AUOUTPUT -v -l-10" sets the volume to -10dB). But it does not work using the config.txt, which would be ideal. Using the verbose output, it does report the volume is set to -10dB, but it does not really change the volume level.
I tried it with and without the RUN command, result is always the same.
My current configuration looks like this:
Code: Select all
[0]
# Start External SPI Flash Chip as device B
dSpi01Fl B
AUODAC s
RUN AuOutput -v -l-10
RUN YBITCLR FC00,D
RUN YBITCLR FC00,C
UARTIN
S:SHELL.AP3
Code: Select all
Hello.
VSOS 3.55 build Mar 26 2018 15:11:17
VLSI Solution Oy 2012-2018 - www.vlsi.fi
Starting the kernel..
Starting Devices...
Internal Flash
Installed system devices:
S: SPI Flash c213, handled by FAT.
Load drivers, config 0...
Driver: dSpi01Fl...
Driver: AUODAC...
Driver: RUN... AuOutput -v -l-10Volume -10.0 dB of maximum level
Driver: RUN... YBITCLR FC00,DFC00,D Y:0xfc00: 0xa000-13 -> 0x8000
Driver: RUN... YBITCLR FC00,CFC00,C Y:0xfc00: 0x8000-12 -> 0x8000
Driver: UARTIN...
Driver: S:SHELL.AP3...
VSOS SHELL
S:>
Code: Select all
S:>auoutput
auoutput
stdaudioout: 0x281e, AUODAC::audioFile=0x0c43(3139)
->Identify(): 0x3bbc, AUODAC::Identify returns "AUODAC"
->op: 0x2825, AUODAC::audioFileOps=0x0000(0)
->Ioctl(): 0x3a84, AUODAC::AudioIoctl
->Write(): 0x3b72, AUODAC::AudioWrite
Sample rate: 48000
Bits per sample: 16
Buffer size: 4096 16-bit words (2048 16-bit stereo samples)
Buffer fill: 4 16-bit words (2 16-bit stereo samples)
Sample counter: 5347150
Underflows: 5345107
Volume: +0.0 dB of maximum level
S:>
S:>
Code: Select all
S:>AuOutput -v -l-10
AuOutput -v -l-10
Volume -10.0 dB of maximum level
S:>
Martin.
Re: New Audio Driver Collection
Hmm, maybe it gets reinitialized somewhere after parsing CONFIG.TXT... or maybe it's really put into effect only when first real sample is played by a decoder, I'm not sure, there's SO many different kinds of volume control handlers that we use.. Henrik would know best.
Can you describe the symptoms, e.g. how do you know that the volume is not correct - do you play some audio files or route audio some other way?
What does AuOutput report when the volume is incorrect? Maybe someone in the kernel or in the ROM inits some HW registers without going through the stdaudioout abstraction, thus causing the HW volume to not be what the abstraction thinks it is... hmm... can you try to run PREG to find the value of DAC_VOL hardware register?
-Panu
Can you describe the symptoms, e.g. how do you know that the volume is not correct - do you play some audio files or route audio some other way?
What does AuOutput report when the volume is incorrect? Maybe someone in the kernel or in the ROM inits some HW registers without going through the stdaudioout abstraction, thus causing the HW volume to not be what the abstraction thinks it is... hmm... can you try to run PREG to find the value of DAC_VOL hardware register?
-Panu
Info: Line In and Line Out, VS1000 User interface, Overlay howto, Latest VSIDE, MCU Howto, Youtube
Panu-Kristian Poiksalo
Panu-Kristian Poiksalo
Re: New Audio Driver Collection
Hello Panu, thank you for the response,
When I use "AuOutput -v -l-10" command in shell, the reported value is "Volume: -10.0 dB of maximum level" and output level is 300mV rms indeed.
Martin.
Not really, no matter how many times I play file the level is always the same.
I'm using Playfile.dl3 to play mp3 file on standard audio output. I'm measuring the output level with oscilloscope on the left channel, so I can clearly see true output level.
Real output level always does match the value of auoutput report, so with the report in my previous post: "Volume: +0.0 dB of maximum level", the audio really is 0dB (cca 1Vrms).
When I use "AuOutput -v -l-10" command in shell, the reported value is "Volume: -10.0 dB of maximum level" and output level is 300mV rms indeed.
Seems possible, sure can try the PREG, how exactly do I use it? From command help I suppose it can be "PREG DAC_VOL", but it does not return anything in the shell.. I may be missing some other dependent driver..?Panu wrote: ↑Tue 2018-05-29 10:36 Maybe someone in the kernel or in the ROM inits some HW registers without going through the stdaudioout abstraction, thus causing the HW volume to not be what the abstraction thinks it is... hmm... can you try to run PREG to find the value of DAC_VOL hardware register?
Martin.