Update: emu1212m

Update: emu1212m

[James Courtier-Dutton]

Hi,

This is just a quick note to say that I have made some progress with the
alsa support for emu1212m.
Summary:
If one cold boots to windows, and then warm boots to linux, I have
managed to get SPDIF out working on the emu1212m.
This is good news, because I have managed to determine the final bit of
work required to get the emu1212m working in Linux.
The emu1212m has a FPGA on it.
1) The FPGA array is filled with the netlists.
2) The FPGA now has registers that can be read and written to switch
features on and off. E.g. spdif out or adat out.

Now, I have done a lot of the work for step 2. I just need to work out
how to do step 1 now.
Step 1 happens on cold boot, and survives a warm boot.
Step 2 is already understood in the Linux driver.

Summary:
TODO: Step 1.

James

Re: Update: emu1212m

[James Courtier-Dutton]

James Courtier-Dutton wrote:
> Hi,
> 
> This is just a quick note to say that I have made some progress with the
> alsa support for emu1212m.
> Summary:
> If one cold boots to windows, and then warm boots to linux, I have
> managed to get SPDIF out working on the emu1212m.
> This is good news, because I have managed to determine the final bit of
> work required to get the emu1212m working in Linux.
> The emu1212m has a FPGA on it.
> 1) The FPGA array is filled with the netlists.
> 2) The FPGA now has registers that can be read and written to switch
> features on and off. E.g. spdif out or adat out.
> 
> Now, I have done a lot of the work for step 2. I just need to work out
> how to do step 1 now.
> Step 1 happens on cold boot, and survives a warm boot.
> Step 2 is already understood in the Linux driver.
> 
> Summary:
> TODO: Step 1.
> 
> James
> 
Update: I have now discovered how 1 works. I just need to write some
code to get it working.

Question:
For (1), the FPGA array is filled with 78756 bytes of netlist code.
I suppose one could consider this 78756 bytes as firmware.
Should this firmware sit somewhere in userspace?
The trouble is, that if one changes some controls on the device, e.g.
switching from SPDIF to ADAT digital outputs, a whole new different
firmware image is loaded. So, one has multiple different firmware
images, with one swapping between them. Should these firmware images be
left in the kernel then, instead of using the userspace firmware api?

James

Re: Update: emu1212m

[Jaroslav Kysela]

On Wed, 21 Jun 2006, James Courtier-Dutton wrote:

> Update: I have now discovered how 1 works. I just need to write some
> code to get it working.
> 
> Question:
> For (1), the FPGA array is filled with 78756 bytes of netlist code.
> I suppose one could consider this 78756 bytes as firmware.
> Should this firmware sit somewhere in userspace?
> The trouble is, that if one changes some controls on the device, e.g.
> switching from SPDIF to ADAT digital outputs, a whole new different
> firmware image is loaded. So, one has multiple different firmware
> images, with one swapping between them. Should these firmware images be
> left in the kernel then, instead of using the userspace firmware api?

I think that the hardware configuration might be implemented using kernel 
module options, so that we can leave the firmware in the user space. It 
will also avoid FPGA design switching when default settings would be 
replaced with the user selected one using alsactl.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs

Re: Update: emu1212m

[Sergey Vlasov]

[-- Attachment #1.1: Type: text/plain, Size: 1307 bytes --]

On Wed, Jun 21, 2006 at 08:56:52AM +0100, James Courtier-Dutton wrote:
> For (1), the FPGA array is filled with 78756 bytes of netlist code.
> I suppose one could consider this 78756 bytes as firmware.
> Should this firmware sit somewhere in userspace?

Probably must, due to license issues :(

> The trouble is, that if one changes some controls on the device, e.g.
> switching from SPDIF to ADAT digital outputs, a whole new different
> firmware image is loaded. So, one has multiple different firmware
> images, with one swapping between them. Should these firmware images be
> left in the kernel then, instead of using the userspace firmware api?

There are some drivers in the kernel which load different firmware images
in different modes.  E.g., the ipw2200 driver can load ipw2200-bss.fw,
ipw2200-ibss.fw or ipw2200-sniffer.fw depending on the mode set by
iwconfig (and can switch between them at runtime).

There is also an option to use a single firmware file consisting of
multiple parts used for different modes, but this obviously has a higher
memory overhead.  IMHO this should be used only when there are some
latency restrictions for switching modes (so that a driver can request all
firmware parts during initialization and then load different parts without
waiting for userspace helpers).

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: Update: emu1212m

[Takashi Iwai]

At Wed, 21 Jun 2006 13:14:47 +0400,
Sergey Vlasov wrote:
> 
> > The trouble is, that if one changes some controls on the device, e.g.
> > switching from SPDIF to ADAT digital outputs, a whole new different
> > firmware image is loaded. So, one has multiple different firmware
> > images, with one swapping between them. Should these firmware images be
> > left in the kernel then, instead of using the userspace firmware api?
> 
> There are some drivers in the kernel which load different firmware images
> in different modes.  E.g., the ipw2200 driver can load ipw2200-bss.fw,
> ipw2200-ibss.fw or ipw2200-sniffer.fw depending on the mode set by
> iwconfig (and can switch between them at runtime).
> 
> There is also an option to use a single firmware file consisting of
> multiple parts used for different modes, but this obviously has a higher
> memory overhead.  IMHO this should be used only when there are some
> latency restrictions for switching modes (so that a driver can request all
> firmware parts during initialization and then load different parts without
> waiting for userspace helpers).

Well, from programming perspective, keeping all firmware images
would be easier, so I would implement the cached images at first.
In addition, these images are also useful to implement
suspend/resume.


Takashi

Re: Update: emu1212m

[James Courtier-Dutton]

Takashi Iwai wrote:
> At Wed, 21 Jun 2006 13:14:47 +0400,
> Sergey Vlasov wrote:
>   
>>> The trouble is, that if one changes some controls on the device, e.g.
>>> switching from SPDIF to ADAT digital outputs, a whole new different
>>> firmware image is loaded. So, one has multiple different firmware
>>> images, with one swapping between them. Should these firmware images be
>>> left in the kernel then, instead of using the userspace firmware api?
>>>       
>> There are some drivers in the kernel which load different firmware images
>> in different modes.  E.g., the ipw2200 driver can load ipw2200-bss.fw,
>> ipw2200-ibss.fw or ipw2200-sniffer.fw depending on the mode set by
>> iwconfig (and can switch between them at runtime).
>>
>> There is also an option to use a single firmware file consisting of
>> multiple parts used for different modes, but this obviously has a higher
>> memory overhead.  IMHO this should be used only when there are some
>> latency restrictions for switching modes (so that a driver can request all
>> firmware parts during initialization and then load different parts without
>> waiting for userspace helpers).
>>     
>
> Well, from programming perspective, keeping all firmware images
> would be easier, so I would implement the cached images at first.
> In addition, these images are also useful to implement
> suspend/resume.
>
>
> Takashi
>   

Ok, but if I am going to cache the images, I might as well just include 
them in the driver .c code. The space taken up will be the same.
I suppose the advantage of using the cache, it that the images are then 
only loaded for the card variants that need it. I.e. loaded for 
emu1212m, but not loaded to Audigy2.

James

Re: Update: emu1212m

[James Courtier-Dutton]

Sergey Vlasov wrote:
> On Wed, Jun 21, 2006 at 08:56:52AM +0100, James Courtier-Dutton wrote:
>   
>> For (1), the FPGA array is filled with 78756 bytes of netlist code.
>> I suppose one could consider this 78756 bytes as firmware.
>> Should this firmware sit somewhere in userspace?
>>     
>
> Probably must, due to license issues :(
>   
Fortunately, licensing is not an issue. They donated the emu1212m card 
to me. I have a signed agreement with them that I can write source code 
for the creative sound cards and publish them as GPL. I just can't 
publish or pass on any documents they might have sent me to help me in 
that task.

>   
>> The trouble is, that if one changes some controls on the device, e.g.
>> switching from SPDIF to ADAT digital outputs, a whole new different
>> firmware image is loaded. So, one has multiple different firmware
>> images, with one swapping between them. Should these firmware images be
>> left in the kernel then, instead of using the userspace firmware api?
>>     
>
> There are some drivers in the kernel which load different firmware images
> in different modes.  E.g., the ipw2200 driver can load ipw2200-bss.fw,
> ipw2200-ibss.fw or ipw2200-sniffer.fw depending on the mode set by
> iwconfig (and can switch between them at runtime).
>
> There is also an option to use a single firmware file consisting of
> multiple parts used for different modes, but this obviously has a higher
> memory overhead.  IMHO this should be used only when there are some
> latency restrictions for switching modes (so that a driver can request all
> firmware parts during initialization and then load different parts without
> waiting for userspace helpers).
>   

Are all those threee fw images loaded into the driver cache memory from 
userspace at modprobe time, or is each one loaded from userspace each 
time a iwconfig mode changes?
I don't yet know how many different images I will have to play with. I 
have so far counted the presence of 2.
Is leaving them cached in driver kernel memory considered bad practice, 
and wasteful of memory space?

James

Re: Update: emu1212m

[Takashi Iwai]

At Wed, 21 Jun 2006 12:58:27 +0100,
James Courtier-Dutton wrote:
> 
> >> The trouble is, that if one changes some controls on the device, e.g.
> >> switching from SPDIF to ADAT digital outputs, a whole new different
> >> firmware image is loaded. So, one has multiple different firmware
> >> images, with one swapping between them. Should these firmware images be
> >> left in the kernel then, instead of using the userspace firmware api?
> >>     
> >
> > There are some drivers in the kernel which load different firmware images
> > in different modes.  E.g., the ipw2200 driver can load ipw2200-bss.fw,
> > ipw2200-ibss.fw or ipw2200-sniffer.fw depending on the mode set by
> > iwconfig (and can switch between them at runtime).
> >
> > There is also an option to use a single firmware file consisting of
> > multiple parts used for different modes, but this obviously has a higher
> > memory overhead.  IMHO this should be used only when there are some
> > latency restrictions for switching modes (so that a driver can request all
> > firmware parts during initialization and then load different parts without
> > waiting for userspace helpers).
> >   
> 
> Are all those threee fw images loaded into the driver cache memory from 
> userspace at modprobe time, or is each one loaded from userspace each 
> time a iwconfig mode changes?
> I don't yet know how many different images I will have to play with. I 
> have so far counted the presence of 2.
> Is leaving them cached in driver kernel memory considered bad practice, 
> and wasteful of memory space?

This depends on the size and on how often you need to use them.
Reading fw images invokes many processes, so it itself is no light
job.

Moreover, for the proper suspend/resume, you need anyway the firmware
image.  It'll be a bit tricky without cached fw images on memory.


Takashi

Re: Update: emu1212m

[James Courtier-Dutton]

James Courtier-Dutton wrote:
> Hi,
> 
> This is just a quick note to say that I have made some progress with the
> alsa support for emu1212m.
> Summary:
> If one cold boots to windows, and then warm boots to linux, I have
> managed to get SPDIF out working on the emu1212m.
> This is good news, because I have managed to determine the final bit of
> work required to get the emu1212m working in Linux.
> The emu1212m has a FPGA on it.
> 1) The FPGA array is filled with the netlists.
> 2) The FPGA now has registers that can be read and written to switch
> features on and off. E.g. spdif out or adat out.
> 
> Now, I have done a lot of the work for step 2. I just need to work out
> how to do step 1 now.
> Step 1 happens on cold boot, and survives a warm boot.
> Step 2 is already understood in the Linux driver.
> 
> Summary:
> TODO: Step 1.
> 
> James
> 

Here is a small update. I have now completed (1) and (2), but a new
problem remains.
(3) The samples are not actually getting from the DSP to the SPDIF unharmed.

I am making further investigations into this, but no luck so far.

James

Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: Update: emu1212m

[James Courtier-Dutton]

James Courtier-Dutton wrote:
> James Courtier-Dutton wrote:
>> Hi,
>>
>> This is just a quick note to say that I have made some progress with the
>> alsa support for emu1212m.
>> Summary:
>> If one cold boots to windows, and then warm boots to linux, I have
>> managed to get SPDIF out working on the emu1212m.
>> This is good news, because I have managed to determine the final bit of
>> work required to get the emu1212m working in Linux.
>> The emu1212m has a FPGA on it.
>> 1) The FPGA array is filled with the netlists.
>> 2) The FPGA now has registers that can be read and written to switch
>> features on and off. E.g. spdif out or adat out.
>>
>> Now, I have done a lot of the work for step 2. I just need to work out
>> how to do step 1 now.
>> Step 1 happens on cold boot, and survives a warm boot.
>> Step 2 is already understood in the Linux driver.
>>
>> Summary:
>> TODO: Step 1.
>>
>> James
>>
> 
> Here is a small update. I have now completed (1) and (2), but a new
> problem remains.
> (3) The samples are not actually getting from the DSP to the SPDIF unharmed.
> 
> I am making further investigations into this, but no luck so far.
> 
> James

I received a very welcome email today. :-)
It contained some datasheets for the emu1212m FPGA from emu.com
themselves. :-)

I have now managed to get SPDIF output working from the emu1212m SPDIF
out to a SPDIF capture card in a different PC. The samples appear to be
unharmed. I have "speaker-test -c2 -tsine -Dfront" outputting samples
through the emu1212m. A sine wave then appears on the input of another
PC with an SPDIF capture card. I have not yet verified if the samples
are being interpolated or not.

The datasheets should give me enough information in order to get full
192kHz Audio capture and playback working, but that will take a rather
large rework of the snd-emu10k1 driver. For example, 48kHz stereo uses 2
FX_BUS channels, 96kHz mono uses 4, 192kHz uses 8!
The snd-emu10k1 driver is currently only set up to output 48kHz stereo
using 2 FX_BUS channels.

So, initially, I will only be implementing support for SPDIF and DAC/ADC
inputs/outputs at 48kHz.

My code needs a lot of clean up now, but I hope to be checking it in to
hg this weekend. :-)

Cheers

James


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642