ADC and SPDIF questions

[Radoslaw Szkodzinski]

Hello,

I'm interested in using cubieboard as a standalone audio DSP.
To that end, I need more information on the ADC specifications and SPDIF pins.

Is the ADC any good? (e.g. stereo, 16 bit or better, at least 44100 Hz)

Is there any way to access I2S directly?

SPDIF level question has a separate thread, I'd like to know it too.

Does cubieboard happen to have a li-ion battery controller?

Thanks in advance for the answers.
--
Radosław Szkodziński

[Tom Cubie]

On Mon, Oct 1, 2012 at 9:50 PM, Radoslaw Szkodzinski
<astra...@gmail.com> wrote:
> Hello,
>
> I'm interested in using cubieboard as a standalone audio DSP.
> To that end, I need more information on the ADC specifications and SPDIF pins.
>
> Is the ADC any good? (e.g. stereo, 16 bit or better, at least 44100 Hz)

For the ADC, please refer to the A10 datasheet
http://linux-sunxi.org/images/3/33/A10_Datasheet.pdf

>
> Is there any way to access I2S directly?

Currently no.

>
> SPDIF level question has a separate thread, I'd like to know it too.
>
> Does cubieboard happen to have a li-ion battery controller?

We will add it in the next next revision.
The next revision will be a bug fix for the currently hardware and the
next next revision will add I2S, RTC, battery etc..

>
> Thanks in advance for the answers.
> --
> Radosław Szkodziński
>

> --
>
>



--
Keep simple, stay foolish.

[Anthony Maciel]

On Monday, October 1, 2012 7:10:47 AM UTC-7, mr.hipboi wrote:

We will add it in the next next revision.
The next revision will be a bug fix for the currently hardware and the
next next revision will add I2S, RTC, battery etc..

--
Keep simple, stay foolish.

What time frame are we looking for the 'next next' revision? Will that be the "general availability" version that gets sent out, or is it more down the line as a follow up after being generally available? I too am really interested in a battery based version.

I'm sure it would, but the battery controller should provide the full functionality of running on LiPo, from handling the charging to automatically selecting the power source depending on availability, correct? And all we would have to do is plug in the battery in to the socket? 

Thanks,

--

Anthony

[amix]

On Monday, October 1, 2012 3:51:11 PM UTC+2, astralstorm wrote:

Hello,

I'm interested in using cubieboard as a standalone audio DSP.

What kind of project do you plan? I am seeking for an ARM based BruteFIR (or similare, free, opensource) solution. However, it seems, that BruteFIR uses Assembler code, partially, which has been written for x86. It would mean a re-write of that parts for ARM based systems. Do you know anythig, that I don't ;) Thanks.

[jons...@gmail.com]

Doesn't bruteFIR use libfftw? If so libfftw already has ASM level NEON
support in it.

I suspect the Cedar mpeg encode/decode hardware is capable of doing
FFTs much faster than the NEON unit. But we'd have to beg until we can
get some documentation for it.

After Cubieboard gets fixed to expose the I2S lines it would be
interesting to do an audio shield using something like a TI TAS5508.
There are very few (are there any?) I2S audio boards for hackers to
play with.

The Cubieboard would run DRC (based on BruteFIR) and send the output
to the TAS5508. http://drc-fir.sourceforge.net/

Are there other audio chips that might be better than the TAS5508?

--
Jon Smirl
jons...@gmail.com

[Radoslaw Szkodzinski]

Actually, something quite related - a long dual stereo (or more)
convolution kernel is one of the steps.

I've checked and libfftw has hardware support for both NEON and VFP.
Should have more than acceptable performance - the real question is
whether ADC/DAC will do (will have to measure) or I'll have to supply
my own. I'll definitely supply analog parts for input isolation and
preamp myself.

Cubieboard would do very nicely as the computation and control module.

--
Radosław Szkodziński

[Radoslaw Szkodzinski]

On Mon, Oct 1, 2012 at 7:34 PM, jons...@gmail.com <jons...@gmail.com> wrote:
> Doesn't bruteFIR use libfftw? If so libfftw already has ASM level NEON
> support in it.
>
> I suspect the Cedar mpeg encode/decode hardware is capable of doing
> FFTs much faster than the NEON unit. But we'd have to beg until we can
> get some documentation for it.

Very likely, at least the DFT. Not sure about necessary second MAC
step or memory performance.
Obviously will need more coding.

> After Cubieboard gets fixed to expose the I2S lines it would be
> interesting to do an audio shield using something like a TI TAS5508.
> There are very few (are there any?) I2S audio boards for hackers to
> play with.
>
> The Cubieboard would run DRC (based on BruteFIR) and send the output
> to the TAS5508. http://drc-fir.sourceforge.net/

And here, Cubieboard would run HRTF transform and perhaps some basic
head tracking (later?) for headphone usage.

> Are there other audio chips that might be better than the TAS5508?

Mouser stocks good selection of high end Cirrus Logic ADC/DACs, e.g.
CS4272. Wolfson can be used as well, but CLs are cheaper and as good
if not messed up in implementation.
The tricky part is always the analog one.

--
Radosław Szkodziński

[Scott Castaline]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The referenced bug fix for the next version can that be field
reworked? If it can will there be rework instructions for applying the
fix(es)?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBAgAGBQJQampCAAoJEIefqZ0kni1dSEgP+gIhoe2tte7vg3ZgrdHjG6R/
nmaul+UTU9FxSDc+mR2LG0E2EpBguUReG8fK0FIveRuPhmyS5RN/bG0+KNrNgGQe
AHNI1JLUaN8keLAn0zXfTI0wF/o3CURZYHLFN9unHPzZKJOMe/FuRZ5bgJecwteV
FAxfhvTp1j04KE3huVXsH4Lb1wy587QNRUFx95hGfCkPgOK5ATkz4U/Ac83MB8dY
HMpgYvHkmXdgmaEBn2o8FTmtSBq26nwtBzmusR/9qXjfO2NYbbr97GJYhTXSZ2JD
XmkifawQhcts0hFQO+szcAilk3m1X/neQyiP2E2eiOwIZanSKWuAbd7m6Zi9KbCU
dZ2IIU/wp7EAN6X+s1IDJsNAPDmDrT1uhR+yLw2BWYLiCacbbsjXoBrz+AOb4ie2
KkI6YEpbfQxbkM9FUYrlgBxuaANeoi06o/I3v4JCOd7ZLjYMm5BtjCSjOR79UVHd
VeO8B/Iz7LUbl9GzJUdjHU4C5tz7G71PoA2YM6NCzdYREcxF37EhcO+Mlq2KIjLB
ROBPQbQui1TAoTlBZ4SIbz9kAd54F+MjRylnmh3p59/Q5a4BbeTsCTvQbd7yX000
oL++21yphMSRG5+cfhPojG4o4vUMemBQH9r0K+qGELw3TRFtif4CRC7vGowtLV8k
kwQVxrxESD9neFCfYNlc
=ZN/u
-----END PGP SIGNATURE-----

[Alejandro Mery]

On 2 October 2012 06:14, Scott Castaline <skot...@gmail.com> wrote:
> The referenced bug fix for the next version can that be field
> reworked? If it can will there be rework instructions for applying the
> fix(es)?

if your board has a big black blob/spot on the back, it's fixed.

[amix]

On Monday, October 1, 2012 7:34:50 PM UTC+2, Jon Smirl wrote:

Doesn't bruteFIR use libfftw? If so libfftw already has ASM level NEON
support in it.

 
I didn't know this. Last information I had was, that the BruteFIR author did not want to support ARM and in the docs he wrote about asm routines, so I combined the two.

 

I suspect the Cedar mpeg encode/decode hardware is capable of doing
FFTs much faster than the NEON unit. But we'd have to beg until we can
get some documentation for it.

Never heard about this hardware. Do you think, that the A10 will be too slow for DRC? Actually, as far as I know, the most important thing seems to be the memory speed (and size?). I would go x86, but the idea, to have a little Mele A2000 connected to my amplifier/speakers, install Linux with BruteFIR onto it, plug in a hard-disk with FLAC and have it serve my audio-needs is very nice. I even want to go further and think about connecting the CubieBoard to the chip of my DAC (Buffalo-II, ESS Sabre), doing something like the HifiDuino, with the CubieBoard instead an Arduino. Not sure, whether this is realistic. It would mean, I'd have to route the input signal through the CubieBoard, first, apply the convolution, and feed it into the DAC. 

Greetings, Andreas

[amix]

On Monday, October 1, 2012 7:49:55 PM UTC+2, astralstorm wrote:

 

Actually, something quite related - a long dual stereo (or more)
convolution kernel is one of the steps.

I've checked and libfftw has hardware support for both NEON and VFP.
Should have more than acceptable performance - the real question is
whether ADC/DAC will do (will have to measure) or I'll have to supply
my own. I'll definitely supply analog parts for input isolation and
preamp myself.

Are you going to document it? Would be very nice, indeed :-)
 

Cubieboard would do very nicely as the computation and control module.

It could control a display, the DAC, actually all the electronics in a Preamp/DAC, as well as do the DRC. If this would work, it would be mighty! :-) On the other side, I wonder, how much electrical noise electronics like these to add.
 

[jons...@gmail.com]

On Tue, Oct 2, 2012 at 1:57 PM, amix <mixich....@gmail.com> wrote:
> On Monday, October 1, 2012 7:34:50 PM UTC+2, Jon Smirl wrote:
>>
>> Doesn't bruteFIR use libfftw? If so libfftw already has ASM level NEON
>> support in it.
>
>
> I didn't know this. Last information I had was, that the BruteFIR author did
> not want to support ARM and in the docs he wrote about asm routines, so I
> combined the two.

Looks like there are two pieces of ASM, one in libfftw and one in
brutefir. libfftw has good ARM NEON code. brutefir probably needs some
work.

Google around for implementations. One paper on filtering I looked at
said optimizing with hand NEON would be good for about 2x over what
the compiler will do.

Implementing this in hand ASM is not that hard. Let the compiler
generate an assembly listing from the C code. Then switch the build
over to use that ASM file. Start making small improvements to the ASM
code. In general a decent amount of trial and error is required to
make the fastest code. You will think some optimizations are going to
be faster and they end up being slower.

>
>>
>> I suspect the Cedar mpeg encode/decode hardware is capable of doing
>> FFTs much faster than the NEON unit. But we'd have to beg until we can
>> get some documentation for it.
>
>
> Never heard about this hardware. Do you think, that the A10 will be too slow
> for DRC?

The Cedar hardware is inside the A10 chip. It is used for video
processing. After you finish play around with NEON that is the next
place to get speed gains.

The speed gains translate into more points in the FIR filter. The more
points, the smoother it gets.

koonlab.com is not responding right now. If it comes back up it shows
you how to do million point DRC on a GPU.

>Actually, as far as I know, the most important thing seems to be
> the memory speed (and size?). I would go x86, but the idea, to have a little

The limit is FPU speed first, then memory architecture. For example an
identically clocked PPC will beat ARM by about 30% because it has a
better memory architecture.

x86 wins for two reasons - it is running at 4Ghz, and it has SSE. A
GPU can 20x what a CPU can do.

> Mele A2000 connected to my amplifier/speakers, install Linux with BruteFIR
> onto it, plug in a hard-disk with FLAC and have it serve my audio-needs is
> very nice. I even want to go further and think about connecting the
> CubieBoard to the chip of my DAC (Buffalo-II, ESS Sabre), doing something

It is interesting to work with an all digital system and use a PWM amp
with I2S input. TAS5508 is an example of this.

> like the HifiDuino, with the CubieBoard instead an Arduino. Not sure,
> whether this is realistic. It would mean, I'd have to route the input signal
> through the CubieBoard, first, apply the convolution, and feed it into the
> DAC.
>
> Greetings, Andreas
>

> --
>
>



--
Jon Smirl
jons...@gmail.com

[amix]

Thanks for clarification, Jon.

However, I think I will need to wait for somebody to implement these things, since I am barley capable of ASM coding ;)

It is interesting to work with an all digital system and use a PWM amp
with I2S input. TAS5508 is an example of this.

Is this Chipamp/Gainclone tech? How much output would that have?

[jons...@gmail.com]

On Sat, Oct 6, 2012 at 3:12 AM, amix <mixich....@gmail.com> wrote:
> Thanks for clarification, Jon.
>
> However, I think I will need to wait for somebody to implement these things,
> since I am barley capable of ASM coding ;)

It will still work without the ASM. The C source is there and it will compile.

Handcoding the ASM is just an optimization.

>
>
>> It is interesting to work with an all digital system and use a PWM amp
>> with I2S input. TAS5508 is an example of this.
>
>
> Is this Chipamp/Gainclone tech? How much output would that have?

TAS5508C is a PWM processor SOC. You hook different sized power stage
output chips to it. You can get anywhere from 20W to 300W per channel.
This type of technology is in almost every amp that you'll find in a
place like Best Buy. It is made by many chip vendors.

Chipamp puts both halves of this onto a single chip. That restricts
the heat sink capability limiting you to around 20W.

There is a wealth of info at http://www.diyaudio.com/

[jons...@gmail.com]

On Sat, Oct 6, 2012 at 9:28 AM, jons...@gmail.com <jons...@gmail.com> wrote:
> On Sat, Oct 6, 2012 at 3:12 AM, amix <mixich....@gmail.com> wrote:
>> Thanks for clarification, Jon.
>>
>> However, I think I will need to wait for somebody to implement these things,
>> since I am barley capable of ASM coding ;)
>
> It will still work without the ASM. The C source is there and it will compile.
>
> Handcoding the ASM is just an optimization.
>
>>
>>
>>> It is interesting to work with an all digital system and use a PWM amp
>>> with I2S input. TAS5508 is an example of this.
>>
>>
>> Is this Chipamp/Gainclone tech? How much output would that have?
>
> TAS5508C is a PWM processor SOC. You hook different sized power stage
> output chips to it. You can get anywhere from 20W to 300W per channel.
> This type of technology is in almost every amp that you'll find in a
> place like Best Buy. It is made by many chip vendors.
>
> Chipamp puts both halves of this onto a single chip. That restricts
> the heat sink capability limiting you to around 20W.

I see that chipamp in your context means the LM3875. That is an
analog amp and it needs ADC to make the input. You can build powerful
analog amps too. They are heavy and waste a lot of power.

Here's a picture of a gainclone. Note the gigantic power supply and
heat sink compared to the tiny amp board.
http://circuit-zone.com/ediy_blog/541/lm3875-gainclone-amplifier-power-amp.jpg

>
> There is a wealth of info at http://www.diyaudio.com/
>
>>
>> --
>>
>>
>
>
>
> --
> Jon Smirl
> jons...@gmail.com

--
Jon Smirl
jons...@gmail.com

[Henrik Nordström]

mån 2012-10-01 klockan 22:10 +0800 skrev Tom Cubie:

> The next revision will be a bug fix for the currently hardware and the
> next next revision will add I2S, RTC, battery etc..

Don't forget those JTAG pins please.

Regards
Henrik

[Dorin Comaneanu]

Hi Tom,

Any news with the next, next version? - A20? or A10