snd_pcm_poll_descriptors_revents()

snd_pcm_poll_descriptors_revents()

[FAU]

This function has the signature:
"int snd_pcm_poll_descriptors_revents(snd_pcm_t *pcm, struct pollfd *pfds,
unsigned int nfds, unsigned short *revents)"
It takes a nfds parameter which defines the number of elements of pfds for
which revents shall be collected.
But this interface allows only to return the revents of one fd!
Is this a design error or do I have to interpret it differently.

/FAU




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: snd_pcm_poll_descriptors_revents()

[Jaroslav Kysela]

On Sat, 20 Jul 2002, FAU wrote:

> This function has the signature:
> "int snd_pcm_poll_descriptors_revents(snd_pcm_t *pcm, struct pollfd *pfds,
> unsigned int nfds, unsigned short *revents)"
> It takes a nfds parameter which defines the number of elements of pfds for
> which revents shall be collected.
> But this interface allows only to return the revents of one fd!
> Is this a design error or do I have to interpret it differently.

I don't understand. Simply pass all pollfd structs returned from 
snd_pcm_poll_descriptors() and poll() to this function to collect one 
result to do a simple check in your application. Note that alsa-lib might 
use (for some reason) multiple file descriptors, but we cannot predict the 
purpose of all descriptors so the snd_pcm_poll_descriptors_revents() 
function returns _ONE_ collected result from all internal file 
descriptors.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project  http://www.alsa-project.org
SuSE Linux    http://www.suse.com



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Some cs4630 progress

[Benny Sjostrand]

Hi!

In this moment i've been hacking on the cs46xx alsa driver and hopefully 
i've got something that can make any fustraded cs46xx user/developer a 
little bit happier.
Public documentation about the cs4630 dont seems to exist and as we 
already know, and Cirrus have not been very helpful providing us such 
necesary technical information. Finally Tom. W at Cirrus have provided 
me some DSP assembler sources, and some other related C++ sources. With 
that references i've able to find out some internals of the cs4630 and 
get a little bit further.

The CS4630 runs a mini Real-Time OS inside, called SPOS (Stream 
Processing OS I guess ...), parts of the SPOS is located in ROM memory 
on the CS4630 and CS4612, on the CS4610 got no ROM, and the hole SPOS 
needs be loaded in RAM.
Then it's up to user/driver to setup which tasks should be running 
inside the SPOS, basically here we one basic entry to care of, the SCB 
(stream controll block), then we have 4 task tree, Hyper Foreground, 
Foreground,  and Background. A SCB entry got a few basic things to care 
of, a  address pointer to the next SCB list, a sublist address pointer, 
a function entry pointer. Then it has a lot of other relevant variables 
which depends on which task uses the SCB, but no documentation about 
this, so it's only to test && guess.
In the DSP image with the current ALSA driver all tasks are statically 
setup when load the image.
When the drivers pokes and peeks on the BA1 address space what it 
actually does is to modify and read parameters from a SCB task running 
in the DSP.

So I've been working on using the .osp files provided by the Windows 
driver. To .osp contains a EXPORT segment where from the driver obtain 
the task entry when setting up a SCB, (or a task tree).
The .osp provided by Windows driver dont contain any parameter data, 
which means that all tasks and SCB needs to be setup by the driver. When 
a the CODE in a .osp file is loaded into the DSP on other addres then 
0x0000 all "call()", and  "goto xxxx" instructions needs to be fixed up.

In this moment I've wroten  a program named "ospparser" then generates 
.h  from a .osp which contains a table with all exported symbol, code, 
sample and parameter segments.
Indirectly i can successfully load cwc4630.osp, cwcasync.osp, 
cwcsnoop.osp code into DSP, do all necesary fixups, and have everything 
working just a before, (as with current ALSA driver) All SCB's and 
tasktrees are setup by the driver.

Today i manage to get "signals" out from the SPDIFO interface, however 
the sound is very distorcionated, totally broken, and my minidisc dont 
wont record it, course some copyright
bit in the stream that i've got no idea how i been able to configure it 
in such way.

To make multiple PCM channel, secondary CODEC to work is just to setup 
the necesary SCB's entries, which is hard to know how to do without any 
documenation.

Well, if you want take a look at my  changes to the cs46xx driver, 
however the difference is not "hearable" yet, there a lot of work done, 
download my code at this locations:
http://www.cucumelo.org/~gorm/alsa-driver-0.9.0rc2-bs20020721.tar.gz
http://www.cucumelo.org/~gorm/ospparser.tar.gz

/Benny



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf