[LAU] open hw soundcard

Folderol folderol at ukfsn.org
Mon Nov 16 17:26:03 EST 2009


On Mon, 16 Nov 2009 21:13:54 +0000
Folderol <folderol at ukfsn.org> wrote:

> On Mon, 16 Nov 2009 10:56:17 +0100 (CET)
> karl at aspodata.se (Karl Hammar) wrote:
> 
> > Martin Peach:
> > > >> karl at aspodata.se (Karl Hammar) wrote:
> > ...
> > > >>> If we are going to have multiple analog inputs at higt sample rate,
> > > >>> isn't it better to have a parallell interface. With spi the number of
> > > >>> channels will be limited to something like 8 for a 24bit converter.
> > > >>> Plus that the AT32AP7000/AT91SAM9260 only has two spi-busses.
> > ...
> > > Another way to do that would be to bit-bang 8 SPI devices sharing one 
> > > clock line (and /CS/FS) onto a byte-wide port, read all 8 in parallel 
> > > one bit at a time in perfect sync.
> > > 
> > > It actually should be possible to use a /RD line for an SPI clock, so 24 
> > > successive reads of a single address would clock in 8 24-bit samples.
> > 
> > I tend to dislike bitbanging, but yes, that should be doable, something
> > like:
> > 
> > void read_all_adcs() {
> >   uint32_t adc[32];  // up to 32 adc converters
> >   int ix;
> >   int kx;
> >   uint32_t bits;
> > 
> >   chip_select(0);
> >   // the first few bits are to start converter
> >   bits = get_data();    
> >   bits = get_data();    
> >   bits = get_data();    
> >   bits = get_data();    
> >   bits = get_data();    
> >   for (ix = 0; ix < 24; ix++) {
> >     bits = get_data();    
> >     for (kx = 0; kx < 32; kx++) {
> >       adc[kx] <<= 1;
> >       adc[kx] |= bits & 1;
> >       bits >>= 1;
> >     }
> >   }
> >   chip_select(1);
> > }
> > 
> > I have to think about that. The big "but" would be that the clock
> > (the frequency of get_data()) should be stable, I don't know how much
> > variation is allowed.
> > 
> > Regards,
> > /Karl
> 
> Possibly, the only one that needs to be stable is the one that actually
> initiates the sampling. i.e. number 5. This seems a bit messy, however,
> could numbers 1-4 be done at any time after the previous conversion,
> then number 5 initiated by a very stable hardware clock source, and the
> remaining pulses derived from the processor.
> 
> indeed, turn it round so:
> 
>    chip_select(1); // end of previous cycle
> // some form of minimal time delay
>    chip_select(0);
>    // the first few bits are to start converter
>    bits = get_data();    
>    bits = get_data();    
>    bits = get_data();    
>    bits = get_data();    
> // wait in this state for hardware clock
> 
> Because we've faked a serial fetch would that upset the normal fetch, or
> can we simply make one more than we need and throw it away?

Talking to myself again :)
Too late, it dawned on me that we are no longer talking about using
spi so the above line is nonsense :(

> The hardware clock source could also be used to

generate, not 'transmit'

> the
> syncronising pulse to the network - assuming this card is the master,
> which the first development one will be of course.
> 
> 
> Hmm, we now have a big enough thread for me to create a new fold in my
> mailreader just for these entries :)
> 
OK guys, back to normal!

-- 
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.



More information about the Linux-audio-user mailing list