Intel atom SCH support

[S***@be.thalesgroup.com]

Hello,

After finally succeeding in building and installing for my target kernel, I
get to the tricky stuff : getting sound ...

When ossplay indicated no driver loaded for /dev/dsp, I ran ossinfo -v3 and
got

Version info: OSS 4.2 (b 2004/201102091209) (0x00040100) GPL
Platform: Linux/i686 2.6.34.7-ELinOS-146 #5 PREEMPT Fri Feb 11 08:42:48 CET
2011 (128.1.1.5)

Number of audio devices: 0
Number of audio engines: 0
Number of mixer devices: 0


Device objects
0: osscore0 OSS core services


Mixer devices

Audio devices

Nodes

lspci -s 1b -vnn yields the following :

00:1b.0 Audio device [0403]: Intel Corporation Device [8086:811b] (rev 07)
Subsystem: Intel Corporation Device [8086:8119]
Flags: bus master, fast devsel, latency 0, IRQ 10
Memory at dff3c000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [50] Power Management version 2
Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00

Suspecting an unsupported variant of the chipset, I compared the alsa
hda_intel source against the oss4 devlists and found the the following
devices
(pciid) that are not supported by OSS4:

/* ICH 6..10 */
...
{ PCI_DEVICE(0x8086, 0x2911), .driver_data = AZX_DRIVER_ICH },
...
/* PCH */
...
{ PCI_DEVICE(0x8086, 0x3b57), .driver_data = AZX_DRIVER_ICH },
/* CPT */
{ PCI_DEVICE(0x8086, 0x1c20), .driver_data = AZX_DRIVER_PCH },
/* SCH */
{ PCI_DEVICE(0x8086, 0x811b), .driver_data = AZX_DRIVER_SCH },


Can they be simply added to devlists or do I need to add other modifications
? Restart soundon, reinstall with make or recompile completely ?

The alsa source seems to treat the SCH exactly as the PCH,
except for HDA snooping, which it will enable at init.

As I am not familiar with HD audio, can someone indicate if this feature is
necessary ?

Thanks a lot for any help,

Sven.

P.S. If this list is considered inapproprate for these questions, please
tell me ...



Sven Biebaut
[phone]
***@be.thalesgroup.com
----------------------------------------------------------------------------
-
T COMMUNICATIONS BELGIUM
Rue des Frères Taymans 28, B-1480 Tubize, Belgium
Phone: [phone], fax: +32 (0)2
3912300

[Dev Mazumdar]

you need to load up just two modules osscore and oss_hdaudio - a much
simpler module dependency than ALSA.

Unless the device ids aren't in the oss_hdaudio.c source file. In which
case it should be rather simple to add these device ids, recompile and
start the drivers.

type lspci -vn and check the device/vendor ids for device type 403

OSS provides a "generic" codec driver that should be able to parse 99%
of all HDAudio codecs - any special initialization code can be added to
a codec specific file.


regards
Dev

---------------------------------------------------
4Front Technologies, Inc.
http://www.opensound.com
9826 Beverlywood Street, Los Angeles, CA 90064, USA
Tel: [phone] Fax: [phone]
---------------------------------------------------

Post by S***@be.thalesgroup.com
Hello,
After finally succeeding in building and installing for my target
kernel, I get to the tricky stuff : getting sound ...
When ossplay indicated no driver loaded for /dev/dsp, I ran ossinfo -v3
and got
/Version info: OSS 4.2 (b 2004/201102091209) (0x00040100) GPL/
/Platform: Linux/i686 2.6.34.7-ELinOS-146 #5 PREEMPT Fri Feb 11 08:42:48
CET 2011 (128.1.1.5)/
/Number of audio devices: 0/
/Number of audio engines: 0/
/Number of mixer devices: 0/
/Device objects/
/ 0: osscore0 OSS core services/
/Mixer devices/
/Audio devices/
/Nodes/
/00:1b.0 Audio device [0403]: Intel Corporation Device [8086:811b] (rev
07)/
/ Subsystem: Intel Corporation Device [8086:8119]/
/ Flags: bus master, fast devsel, latency 0, IRQ 10/
/ Memory at dff3c000 (64-bit, non-prefetchable) [size=16K]/
/ Capabilities: [50] Power Management version 2/
/ Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00/
Suspecting an unsupported variant of the chipset, I compared the alsa
hda_intel source against the oss4 devlists and found the the following
devices
/ /* ICH 6..10 *//
/ ... /
/ { PCI_DEVICE(0x8086, 0x2911), .driver_data = AZX_DRIVER_ICH },/
/ .../
/ /* PCH *//
/ .../
/ { PCI_DEVICE(0x8086, 0x3b57), .driver_data = AZX_DRIVER_ICH },/
/ /* CPT *//
/ { PCI_DEVICE(0x8086, 0x1c20), .driver_data = AZX_DRIVER_PCH },/
/ /* SCH *//
/ { PCI_DEVICE(0x8086, 0x811b), .driver_data = AZX_DRIVER_SCH }, /
Can they be simply added to devlists or do I need to add other
modifications ? Restart soundon, reinstall with make or recompile
completely ?
The alsa source seems to treat the SCH exactly as the PCH,
except for HDA snooping, which it will enable at init.
As I am not familiar with HD audio, can someone indicate if this feature
is necessary ?
Thanks a lot for any help,
Sven.
P.S. If this list is considered inapproprate for these questions, please
tell me ...
Sven Biebaut [phone]
-----------------------------------------------------------------------------
***T COMMUNICATIONS BELGIUM*
Rue des Frères Taymans 28, B-1480 Tubize, Belgium
Phone: [phone], fax: [phone]
_______________________________________________
oss-devel mailing list
http://mailman.opensound.com/mailman/listinfo/oss-devel

[S***@be.thalesgroup.com]

Hello,

Sorry for the long delay.

I added the pci deviceid 0x811b to both the etc/devices.list and
kernel/drv/hdaudio/oss_hdaudio.c file and started anewfrom the configure on.
Still no show, my device node is not created, but ossdetec says the drive is
detected.

Browing around in the sources, I found there is another (very different)
oss_hdaudio.c file in prototype/usr/lib/oss/build which also includes a
supported devices table with pciids ...

There the device 0x811b is still missing. On top of the file there is a
comment stating that this is an autogenerated file and should not be changed
manually.

Where and how is this file generated ? Is it sufficient to change this
manually just for test ?

Thanks a lot,

Sven

-----Original Message-----
Dev Mazumdar
Sent: 14 February, 2011 18:52
To: Discussion mailing list for developers of OSS
Subject: Re: [oss-devel] Intel atom SCH support
you need to load up just two modules osscore and oss_hdaudio
- a much simpler module dependency than ALSA.
Unless the device ids aren't in the oss_hdaudio.c source
file. In which case it should be rather simple to add these
device ids, recompile and start the drivers.
type lspci -vn and check the device/vendor ids for device type 403
OSS provides a "generic" codec driver that should be able to
parse 99% of all HDAudio codecs - any special initialization
code can be added to a codec specific file.
regards
Dev
---------------------------------------------------
4Front Technologies, Inc.
http://www.opensound.com
9826 Beverlywood Street, Los Angeles, CA 90064, USA
Tel: [phone] Fax: [phone]
---------------------------------------------------

Post by S***@be.thalesgroup.com
Hello,
After finally succeeding in building and installing for my target
kernel, I get to the tricky stuff : getting sound ...
When ossplay indicated no driver loaded for /dev/dsp, I ran ossinfo
-v3 and got
/Version info: OSS 4.2 (b 2004/201102091209) (0x00040100) GPL/
/Platform: Linux/i686 2.6.34.7-ELinOS-146 #5 PREEMPT Fri Feb 11
08:42:48 CET 2011 (128.1.1.5)/
/Number of audio devices: 0/
/Number of audio engines: 0/
/Number of mixer devices: 0/
/Device objects/
/ 0: osscore0 OSS core services/
/Mixer devices/
/Audio devices/
/Nodes/
/00:1b.0 Audio device [0403]: Intel Corporation Device [8086:811b]
(rev 07)/ / Subsystem: Intel Corporation Device
bus master, fast devsel, latency 0, IRQ 10/ / Memory at dff3c000
(64-bit, non-prefetchable) [size=16K]/ / Capabilities: [50] Power
Management version 2/ / Capabilities: [70] Express Root Complex
Integrated Endpoint, MSI 00/
Suspecting an unsupported variant of the chipset, I

compared the alsa

Post by S***@be.thalesgroup.com
hda_intel source against the oss4 devlists and found the

the following

Post by S***@be.thalesgroup.com
devices
/ /* ICH 6..10 *//
/ ... /
/ { PCI_DEVICE(0x8086, 0x2911), .driver_data = AZX_DRIVER_ICH },/ /
.../ / /* PCH *// / .../ / { PCI_DEVICE(0x8086, 0x3b57),

.driver_data

Post by S***@be.thalesgroup.com
= AZX_DRIVER_ICH },/ / /* CPT *// / { PCI_DEVICE(0x8086, 0x1c20),
.driver_data = AZX_DRIVER_PCH },/ / /* SCH *// / {

PCI_DEVICE(0x8086,

Post by S***@be.thalesgroup.com
0x811b), .driver_data = AZX_DRIVER_SCH }, /
Can they be simply added to devlists or do I need to add other
modifications ? Restart soundon, reinstall with make or recompile
completely ?
The alsa source seems to treat the SCH exactly as the PCH,

except for

Post by S***@be.thalesgroup.com
HDA snooping, which it will enable at init.
As I am not familiar with HD audio, can someone indicate if this
feature is necessary ?
Thanks a lot for any help,
Sven.
P.S. If this list is considered inapproprate for these questions,
please tell me ...
Sven Biebaut [phone]

----------------------------------------------------------------------

Post by S***@be.thalesgroup.com
-------
***T COMMUNICATIONS BELGIUM*
Rue des Frères Taymans 28, B-1480 Tubize, Belgium
Phone: [phone], fax: [phone]
_______________________________________________
oss-devel mailing list
http://mailman.opensound.com/mailman/listinfo/oss-devel

_______________________________________________
oss-devel mailing list
http://mailman.opensound.com/mailman/listinfo/oss-devel

[Yair K.]

Post by S***@be.thalesgroup.com
Hello,
Sorry for the long delay.
I added the pci deviceid 0x811b to both the etc/devices.list and
kernel/drv/hdaudio/oss_hdaudio.c file

IIRC, the check is disabled there... And devices.list is unused.

Post by S***@be.thalesgroup.com
and started anewfrom the configure
on. Still no show, my device node is not created, but ossdetec says the
drive is detected.

Did you add the id to kernel/drv/oss_hdaudio/.devices ?

Post by S***@be.thalesgroup.com
Browing around in the sources, I found there is another (very different)
oss_hdaudio.c file in prototype/usr/lib/oss/build which also includes a
supported devices table with pciids ...
There the device 0x811b is still missing. On top of the file there is a
comment stating that this is an autogenerated file and should not be
changed manually.
Where and how is this file generated ? Is it sufficient to change this
manually just for test ?
Thanks a lot,
Sven

[Dev Mazumdar]

Hi,



Can you send us the output from lspci -v -n on your board?



regards
Dev Mazumdar

---------------------------------------------------
4Front Technologies, Inc.
http://www.opensound.com
9826 Beverlywood Street, Los Angeles, CA 90064, USA
Tel: [phone] Fax: [phone]
---------------------------------------------------

Post by S***@be.thalesgroup.com
Hello,
Sorry for the long delay.
I added the pci deviceid 0x811b to both the etc/devices.list and
kernel/drv/hdaudio/oss_hdaudio.c file and started anewfrom the configure on.
Still no show, my device node is not created, but ossdetec says the drive is
detected.
Browing around in the sources, I found there is another (very different)
oss_hdaudio.c file in prototype/usr/lib/oss/build which also includes a
supported devices table with pciids ...
There the device 0x811b is still missing. On top of the file there is a
comment stating that this is an autogenerated file and should not be changed
manually.
Where and how is this file generated ? Is it sufficient to change this
manually just for test ?
Thanks a lot,
Sven

-----Original Message-----
Dev Mazumdar
Sent: 14 February, 2011 18:52
To: Discussion mailing list for developers of OSS
Subject: Re: [oss-devel] Intel atom SCH support
you need to load up just two modules osscore and oss_hdaudio
- a much simpler module dependency than ALSA.
Unless the device ids aren't in the oss_hdaudio.c source
file. In which case it should be rather simple to add these
device ids, recompile and start the drivers.
type lspci -vn and check the device/vendor ids for device type 403
OSS provides a "generic" codec driver that should be able to
parse 99% of all HDAudio codecs - any special initialization
code can be added to a codec specific file.
regards
Dev
---------------------------------------------------
4Front Technologies, Inc.
http://www.opensound.com
9826 Beverlywood Street, Los Angeles, CA 90064, USA
Tel: [phone] Fax: [phone]
---------------------------------------------------

Post by S***@be.thalesgroup.com
Hello,
After finally succeeding in building and installing for my target
kernel, I get to the tricky stuff : getting sound ...
When ossplay indicated no driver loaded for /dev/dsp, I ran ossinfo
-v3 and got
/Version info: OSS 4.2 (b 2004/201102091209) (0x00040100) GPL/
/Platform: Linux/i686 2.6.34.7-ELinOS-146 #5 PREEMPT Fri Feb 11
08:42:48 CET 2011 (128.1.1.5)/
/Number of audio devices: 0/
/Number of audio engines: 0/
/Number of mixer devices: 0/
/Device objects/
/ 0: osscore0 OSS core services/
/Mixer devices/
/Audio devices/
/Nodes/
/00:1b.0 Audio device [0403]: Intel Corporation Device [8086:811b]
(rev 07)/ / Subsystem: Intel Corporation Device
bus master, fast devsel, latency 0, IRQ 10/ / Memory at dff3c000
(64-bit, non-prefetchable) [size=16K]/ / Capabilities: [50] Power
Management version 2/ / Capabilities: [70] Express Root Complex
Integrated Endpoint, MSI 00/
Suspecting an unsupported variant of the chipset, I

compared the alsa

Post by S***@be.thalesgroup.com
hda_intel source against the oss4 devlists and found the

the following

Post by S***@be.thalesgroup.com
devices
/ /* ICH 6..10 *//
/ ... /
/ { PCI_DEVICE(0x8086, 0x2911), .driver_data = AZX_DRIVER_ICH },/ /
.../ / /* PCH *// / .../ / { PCI_DEVICE(0x8086, 0x3b57),

.driver_data

Post by S***@be.thalesgroup.com
= AZX_DRIVER_ICH },/ / /* CPT *// / { PCI_DEVICE(0x8086, 0x1c20),
.driver_data = AZX_DRIVER_PCH },/ / /* SCH *// / {

PCI_DEVICE(0x8086,

Post by S***@be.thalesgroup.com
0x811b), .driver_data = AZX_DRIVER_SCH }, /
Can they be simply added to devlists or do I need to add other
modifications ? Restart soundon, reinstall with make or recompile
completely ?
The alsa source seems to treat the SCH exactly as the PCH,

except for

Post by S***@be.thalesgroup.com
HDA snooping, which it will enable at init.
As I am not familiar with HD audio, can someone indicate if this
feature is necessary ?
Thanks a lot for any help,
Sven.
P.S. If this list is considered inapproprate for these questions,
please tell me ...
Sven Biebaut [phone]

----------------------------------------------------------------------

Post by S***@be.thalesgroup.com
-------
***T COMMUNICATIONS BELGIUM*
Rue des Frères Taymans 28, B-1480 Tubize, Belgium
Phone: [phone], fax: [phone]
_______________________________________________
oss-devel mailing list
http://mailman.opensound.com/mailman/listinfo/oss-devel

_______________________________________________
oss-devel mailing list
http://mailman.opensound.com/mailman/listinfo/oss-devel

_______________________________________________
oss-devel mailing list
http://mailman.opensound.com/mailman/listinfo/oss-devel

[S***@be.thalesgroup.com]

Post by Yair K.

Post by S***@be.thalesgroup.com
I added the pci deviceid 0x811b to both the etc/devices.list and
kernel/drv/hdaudio/oss_hdaudio.c file

IIRC, the check is disabled there... And devices.list is unused.

Post by S***@be.thalesgroup.com
and started anewfrom the configure
on. Still no show, my device node is not created, but ossdetec says
the drive is detected.

Did you add the id to kernel/drv/oss_hdaudio/.devices ?

Aha, that is the trick :)
I modified the file and the driver builds and inserts fine now.
Ossdetect -d makes the /dev/oss/ hdaudio device nodes just fine now :)

Using ossplay now gives me output, garbled as it is, but output none the
less ...

In order to reduce the number of active channels and to identify the used
jack I muted/unmuted and replayed the sound file repeatedly.
After a while I received a RIRB error (and no sound) on the play. What does
it stand for and where can I look in the code to debug it ?


Thanks,

Sven Biebaut

[Yair K.]

Post by S***@be.thalesgroup.com

Post by Yair K.

Post by S***@be.thalesgroup.com
I added the pci deviceid 0x811b to both the etc/devices.list and
kernel/drv/hdaudio/oss_hdaudio.c file

IIRC, the check is disabled there... And devices.list is unused.

Post by S***@be.thalesgroup.com
and started anewfrom the configure
on. Still no show, my device node is not created, but ossdetec says
the drive is detected.

Did you add the id to kernel/drv/oss_hdaudio/.devices ?

Aha, that is the trick :)
I modified the file and the driver builds and inserts fine now.
Ossdetect -d makes the /dev/oss/ hdaudio device nodes just fine now :)
Using ossplay now gives me output, garbled as it is, but output none the
less ...

Try testing with osstest

Yours,
Yair K.

[S***@be.thalesgroup.com]

Post by S***@be.thalesgroup.com

Post by S***@be.thalesgroup.com

Post by Yair K.

Post by S***@be.thalesgroup.com
I added the pci deviceid 0x811b to both the

etc/devices.list and

Post by S***@be.thalesgroup.com

Post by Yair K.

Post by S***@be.thalesgroup.com
kernel/drv/hdaudio/oss_hdaudio.c file

IIRC, the check is disabled there... And devices.list is unused.

Post by S***@be.thalesgroup.com
and started anewfrom the configure on. Still no show, my device
node is not created, but ossdetec says the drive is detected.

Did you add the id to kernel/drv/oss_hdaudio/.devices ?

Aha, that is the trick :)
I modified the file and the driver builds and inserts fine now.
Ossdetect -d makes the /dev/oss/ hdaudio device nodes just

fine now :)

Post by S***@be.thalesgroup.com
Using ossplay now gives me output, garbled as it is, but

output none

Post by S***@be.thalesgroup.com
the less ...

Try testing with osstest

I can use osstest and it tells me the tests pass ok, but my ears beg to
differ when the speaker is connected ...

Attached is the output of lspci, ossinfo and osstest.


A number of strange side effects :
- when I run osstest multiple times, the output gets a little bit better.
- when osstest plays to the spdif output, I also hear the speaker
- when I change the mut of the blue jack, the next time I play, I get these
RIRB errors ...

Thanks a lot for any possible help,

Sven

[Dev Mazumdar]

What would be more useful is posting the output from the ossmix command
- it will tell us what options are set for the mixer panel.


As for RIRB timeouts when a jack functionality is changed - it usually
implies that the device has been switched off or the device
functionality has been changed from Output to Input.


regards
Dev

---------------------------------------------------
4Front Technologies, Inc.
http://www.opensound.com
9826 Beverlywood Street, Los Angeles, CA 90064, USA
Tel: [phone] Fax: [phone]
---------------------------------------------------

Post by S***@be.thalesgroup.com

Post by S***@be.thalesgroup.com

Post by S***@be.thalesgroup.com

Post by Yair K.

Post by S***@be.thalesgroup.com
I added the pci deviceid 0x811b to both the

etc/devices.list and

Post by S***@be.thalesgroup.com

Post by Yair K.

Post by S***@be.thalesgroup.com
kernel/drv/hdaudio/oss_hdaudio.c file

IIRC, the check is disabled there... And devices.list is unused.

Post by S***@be.thalesgroup.com
and started anewfrom the configure on. Still no show, my device
node is not created, but ossdetec says the drive is detected.

Did you add the id to kernel/drv/oss_hdaudio/.devices ?

Aha, that is the trick :)
I modified the file and the driver builds and inserts fine now.
Ossdetect -d makes the /dev/oss/ hdaudio device nodes just

fine now :)

Post by S***@be.thalesgroup.com
Using ossplay now gives me output, garbled as it is, but

output none

Post by S***@be.thalesgroup.com
the less ...

Try testing with osstest

I can use osstest and it tells me the tests pass ok, but my ears beg to
differ when the speaker is connected ...
Attached is the output of lspci, ossinfo and osstest.
- when I run osstest multiple times, the output gets a little bit better.
- when osstest plays to the spdif output, I also hear the speaker
- when I change the mut of the blue jack, the next time I play, I get these
RIRB errors ...
Thanks a lot for any possible help,
Sven
_______________________________________________
oss-devel mailing list
http://mailman.opensound.com/mailman/listinfo/oss-devel

[S***@be.thalesgroup.com]

Post by Dev Mazumdar
What would be more useful is posting the output from the
ossmix command
- it will tell us what options are set for the mixer panel.
As for RIRB timeouts when a jack functionality is changed -
it usually
implies that the device has been switched off or the device
functionality has been changed from Output to Input.

I attached the original settings. These setting produce a regular
krr...krr...krr..krr
with a faint hint of sinus (from the testfile) underneath.

By muting and unmuting I found that the jack used is fp-green and that there
is a general front mute.

I then mute all channels and unmute the fp-green and the general front.

ossmix jack.green.mute ON
ossmix jack.black.mute ON
ossmix jack.orange.mute ON
ossmix jack.gray.mute ON
ossmix jack.pink.mute ON
ossmix jack.fp-pink.mute ON
ossmix jack.blue.mute ON
ossmix jack.fp-green.mute ON
ossmix record.mix.mute.mic1 ON
ossmix record.mix.mute.fp-mic1 ON
ossmix record.mix.mute.linein1 ON
ossmix record.mix.mute.fp-headphone1 ON
ossmix record.mix.mute.int-cd1 ON
ossmix record.mix.mute.lineout1 ON
ossmix record.mix.mute.green1 ON
ossmix record.mix.mute.black1 ON
ossmix record.mix.mute.orange1 ON
ossmix record.mix.mute.gray1 ON
ossmix record.mix.mute.input-mix1 ON
ossmix record.mix.mute.mic2 ON
ossmix record.mix.mute.fp-mic2 ON
ossmix record.mix.mute.linein2 ON
ossmix record.mix.mute.fp-headphone2 ON
ossmix record.mix.mute.int-cd2 ON
ossmix record.mix.mute.lineout2 ON
ossmix record.mix.mute.green2 ON
ossmix record.mix.mute.black2 ON
ossmix record.mix.mute.orange2 ON
ossmix record.mix.mute.gray2 ON
ossmix record.mix.mute.input-mix2 ON
ossmix misc.front-mute ON
ossmix misc.input-mix-mute1 ON
ossmix misc.rear-mute ON
ossmix misc.input-mix-mute2 ON
ossmix misc.center/lfe-mute ON
ossmix misc.input-mix-mute3 ON
ossmix misc.side-mute ON
ossmix misc.input-mix-mute4 ON
ossmix misc.pcm4-mute ON
ossmix misc.input-mix-mute5 ON

ossmix jack.fp-green.mute OFF
ossmix misc.front-mute OFF

The krr krr krr remains but I lost the sinus. Clearly there are some mutes
too many, but I am totally lost in what controls change what
direction(record vs playback). Especially the mix controls are confusing.

Is there some logic in the numbering 1 and 2 ? Is this the same as left and
right ? Or does it always mix stereo ..

Is the mixing only from analog to digital or also the other way ?

What are the input-mix-mute 1 to 5 ?

How do I affect the spdif output ?

Many thanks,

Sven

[Dev Mazumdar]

Hi,


I wonder why the OSS HDaudio parser is finding so many controls. I
suspect that the BIOS may have some kind of bug and that causes so many
controls. First thing I would recommend is check to see if you have a
BIOS update - kindly apply that.

SOmething is wrong because the device is showing gray1 and gray2 jacks.
I wonder if it's finding the docking station codec as well as the front
panel codec. I guess there's also an HDMI codec.

The MIX controls are basically Summing widgets that take the sum of all
the outputs and inputs as the input.


This may need some special parsing. Try to compile the mixgen2.c file in
utils directory and generate the parsed output (see
http://opensound.hg.sourceforge.net/hgweb/opensound/opensound/file/44441f68d702/utils/mixgen2.c)


best regards
Dev Mazumdar
---------------------------------------------------
4Front Technologies, Inc.
http://www.opensound.com
9826 Beverlywood Street, Los Angeles, CA 90064, USA
Tel: [phone] Fax: [phone]
---------------------------------------------------

Post by S***@be.thalesgroup.com

Post by Dev Mazumdar
What would be more useful is posting the output from the
ossmix command
- it will tell us what options are set for the mixer panel.
As for RIRB timeouts when a jack functionality is changed -
it usually
implies that the device has been switched off or the device
functionality has been changed from Output to Input.

I attached the original settings. These setting produce a regular
krr...krr...krr..krr
with a faint hint of sinus (from the testfile) underneath.
By muting and unmuting I found that the jack used is fp-green and that there
is a general front mute.
I then mute all channels and unmute the fp-green and the general front.
ossmix jack.green.mute ON
ossmix jack.black.mute ON
ossmix jack.orange.mute ON
ossmix jack.gray.mute ON
ossmix jack.pink.mute ON
ossmix jack.fp-pink.mute ON
ossmix jack.blue.mute ON
ossmix jack.fp-green.mute ON
ossmix record.mix.mute.mic1 ON
ossmix record.mix.mute.fp-mic1 ON
ossmix record.mix.mute.linein1 ON
ossmix record.mix.mute.fp-headphone1 ON
ossmix record.mix.mute.int-cd1 ON
ossmix record.mix.mute.lineout1 ON
ossmix record.mix.mute.green1 ON
ossmix record.mix.mute.black1 ON
ossmix record.mix.mute.orange1 ON
ossmix record.mix.mute.gray1 ON
ossmix record.mix.mute.input-mix1 ON
ossmix record.mix.mute.mic2 ON
ossmix record.mix.mute.fp-mic2 ON
ossmix record.mix.mute.linein2 ON
ossmix record.mix.mute.fp-headphone2 ON
ossmix record.mix.mute.int-cd2 ON
ossmix record.mix.mute.lineout2 ON
ossmix record.mix.mute.green2 ON
ossmix record.mix.mute.black2 ON
ossmix record.mix.mute.orange2 ON
ossmix record.mix.mute.gray2 ON
ossmix record.mix.mute.input-mix2 ON
ossmix misc.front-mute ON
ossmix misc.input-mix-mute1 ON
ossmix misc.rear-mute ON
ossmix misc.input-mix-mute2 ON
ossmix misc.center/lfe-mute ON
ossmix misc.input-mix-mute3 ON
ossmix misc.side-mute ON
ossmix misc.input-mix-mute4 ON
ossmix misc.pcm4-mute ON
ossmix misc.input-mix-mute5 ON
ossmix jack.fp-green.mute OFF
ossmix misc.front-mute OFF
The krr krr krr remains but I lost the sinus. Clearly there are some mutes
too many, but I am totally lost in what controls change what
direction(record vs playback). Especially the mix controls are confusing.
Is there some logic in the numbering 1 and 2 ? Is this the same as left and
right ? Or does it always mix stereo ..
Is the mixing only from analog to digital or also the other way ?
What are the input-mix-mute 1 to 5 ?
How do I affect the spdif output ?
Many thanks,
Sven
_______________________________________________
oss-devel mailing list
http://mailman.opensound.com/mailman/listinfo/oss-devel

[Hannu Savolainen]

Hi,

BIOS update cannot fix this kind of problems. Many codecs just have too
many controls that have redundant functionality. Hand coding is probably
the only way to get the mixer to work properly.

Hannu
----

Post by Dev Mazumdar
Hi,
I wonder why the OSS HDaudio parser is finding so many controls. I
suspect that the BIOS may have some kind of bug and that causes so many
controls. First thing I would recommend is check to see if you have a
BIOS update - kindly apply that.
SOmething is wrong because the device is showing gray1 and gray2 jacks.
I wonder if it's finding the docking station codec as well as the front
panel codec. I guess there's also an HDMI codec.
The MIX controls are basically Summing widgets that take the sum of all
the outputs and inputs as the input.
This may need some special parsing. Try to compile the mixgen2.c file in
utils directory and generate the parsed output (see
http://opensound.hg.sourceforge.net/hgweb/opensound/opensound/file/44441f68d702/utils/mixgen2.c)
best regards
Dev Mazumdar
---------------------------------------------------
4Front Technologies, Inc.
http://www.opensound.com
9826 Beverlywood Street, Los Angeles, CA 90064, USA
Tel: [phone] Fax: [phone]
---------------------------------------------------

Post by S***@be.thalesgroup.com

Post by Dev Mazumdar
What would be more useful is posting the output from the
ossmix command
- it will tell us what options are set for the mixer panel.
As for RIRB timeouts when a jack functionality is changed -
it usually
implies that the device has been switched off or the device
functionality has been changed from Output to Input.

I attached the original settings. These setting produce a regular
krr...krr...krr..krr
with a faint hint of sinus (from the testfile) underneath.
By muting and unmuting I found that the jack used is fp-green and that there
is a general front mute.
I then mute all channels and unmute the fp-green and the general front.
ossmix jack.green.mute ON
ossmix jack.black.mute ON
ossmix jack.orange.mute ON
ossmix jack.gray.mute ON
ossmix jack.pink.mute ON
ossmix jack.fp-pink.mute ON
ossmix jack.blue.mute ON
ossmix jack.fp-green.mute ON
ossmix record.mix.mute.mic1 ON
ossmix record.mix.mute.fp-mic1 ON
ossmix record.mix.mute.linein1 ON
ossmix record.mix.mute.fp-headphone1 ON
ossmix record.mix.mute.int-cd1 ON
ossmix record.mix.mute.lineout1 ON
ossmix record.mix.mute.green1 ON
ossmix record.mix.mute.black1 ON
ossmix record.mix.mute.orange1 ON
ossmix record.mix.mute.gray1 ON
ossmix record.mix.mute.input-mix1 ON
ossmix record.mix.mute.mic2 ON
ossmix record.mix.mute.fp-mic2 ON
ossmix record.mix.mute.linein2 ON
ossmix record.mix.mute.fp-headphone2 ON
ossmix record.mix.mute.int-cd2 ON
ossmix record.mix.mute.lineout2 ON
ossmix record.mix.mute.green2 ON
ossmix record.mix.mute.black2 ON
ossmix record.mix.mute.orange2 ON
ossmix record.mix.mute.gray2 ON
ossmix record.mix.mute.input-mix2 ON
ossmix misc.front-mute ON
ossmix misc.input-mix-mute1 ON
ossmix misc.rear-mute ON
ossmix misc.input-mix-mute2 ON
ossmix misc.center/lfe-mute ON
ossmix misc.input-mix-mute3 ON
ossmix misc.side-mute ON
ossmix misc.input-mix-mute4 ON
ossmix misc.pcm4-mute ON
ossmix misc.input-mix-mute5 ON
ossmix jack.fp-green.mute OFF
ossmix misc.front-mute OFF
The krr krr krr remains but I lost the sinus. Clearly there are some mutes
too many, but I am totally lost in what controls change what
direction(record vs playback). Especially the mix controls are confusing.
Is there some logic in the numbering 1 and 2 ? Is this the same as left and
right ? Or does it always mix stereo ..
Is the mixing only from analog to digital or also the other way ?
What are the input-mix-mute 1 to 5 ?
How do I affect the spdif output ?
Many thanks,
Sven
_______________________________________________
oss-devel mailing list
http://mailman.opensound.com/mailman/listinfo/oss-devel

_______________________________________________
oss-devel mailing list
http://mailman.opensound.com/mailman/listinfo/oss-devel

[S***@be.thalesgroup.com]

-----Original Message-----
Dev Mazumdar
Sent: 23 February, 2011 19:32
To: Discussion mailing list for developers of OSS
Subject: Re: [oss-devel] Intel atom SCH support
Hi,
I wonder why the OSS HDaudio parser is finding so many
controls. I suspect that the BIOS may have some kind of bug
and that causes so many controls. First thing I would
recommend is check to see if you have a BIOS update - kindly
apply that.
SOmething is wrong because the device is showing gray1 and
gray2 jacks.
I wonder if it's finding the docking station codec as well as
the front panel codec. I guess there's also an HDMI codec.
The MIX controls are basically Summing widgets that take the
sum of all the outputs and inputs as the input.
This may need some special parsing. Try to compile the
mixgen2.c file in
utils directory and generate the parsed output (see
http://opensound.hg.sourceforge.net/hgweb/opensound/opensound/
file/44441f68d702/utils/mixgen2.c)

I attached the output of the mixgen command to the mail.

The results are interesting : it mentions spdif in and outs and I do have 2
physical digital jacks on my board, but there are no mixcontrols in the
general mixer to mute them. This could be the reason (or part of it .. )
that when osstest tests the spdif that I hear it on the analog jack ...

Thank you for any possible pointers,

Sven

[S***@be.thalesgroup.com]

Hello,

Post by Dev Mazumdar

-----Original Message-----
Mazumdar
Sent: 23 February, 2011 19:32
To: Discussion mailing list for developers of OSS
Subject: Re: [oss-devel] Intel atom SCH support
Hi,
I wonder why the OSS HDaudio parser is finding so many controls. I
suspect that the BIOS may have some kind of bug and that causes so
many controls. First thing I would recommend is check to see if you
have a BIOS update - kindly apply that.

To exclude hardware or BIOS problems, I used a different atom based board
that we had lying around
(other hardware vendor). Both are identical where audio chain is concerned
(intel US15W SCH and ALC888 codec)

Ossplay, osstest and ossmix have exactly the same behaviour.

Post by Dev Mazumdar

SOmething is wrong because the device is showing gray1 and
gray2 jacks.
I wonder if it's finding the docking station codec as well as the
front panel codec. I guess there's also an HDMI codec.
The MIX controls are basically Summing widgets that take the sum of
all the outputs and inputs as the input.

If the mixer takes also the outputs as input, it can explain why I have a
periodic noise on top of my signal.
How do I break this loopback ?

Where does the mixer output the sum of all signals to ? Straight to the DAC
or is the mixer after the DAC?

Post by Dev Mazumdar

This may need some special parsing. Try to compile the

mixgen2.c file

in utils directory and generate the parsed output (see
http://opensound.hg.sourceforge.net/hgweb/opensound/opensound/
file/44441f68d702/utils/mixgen2.c)

I attached the output of the mixgen command to the mail.
The results are interesting : it mentions spdif in and outs
and I do have 2 physical digital jacks on my board, but there
are no mixcontrols in the general mixer to mute them. This
could be the reason (or part of it .. ) that when osstest
tests the spdif that I hear it on the analog jack ...

I tried looking on the OSS4 webpages for pointers on how to customize the
parsing,
but couldn't find any.

Please advise,

Sven

[Dev Mazumdar]

Hi,


I wonder if you have tried the ALSA drivers on a Linux 2.6 kernel on
this board and see if ALSA works - there seems to be a lot of hand
tuning of the HDAudio mixer in ALSA vs OSS. Perhaps someone has figured
out how to initialize the codec in ALSA. We can also implement similar
dedicated mixer panels in OSS.

Unfortunately without access to the hardware it's quite difficult.


regards
Dev

---------------------------------------------------
4Front Technologies, Inc.
http://www.opensound.com
9826 Beverlywood Street, Los Angeles, CA 90064, USA
Tel: [phone] Fax: [phone]
---------------------------------------------------

Post by S***@be.thalesgroup.com
Hello,

Post by Dev Mazumdar

-----Original Message-----
Mazumdar
Sent: 23 February, 2011 19:32
To: Discussion mailing list for developers of OSS
Subject: Re: [oss-devel] Intel atom SCH support
Hi,
I wonder why the OSS HDaudio parser is finding so many controls. I
suspect that the BIOS may have some kind of bug and that causes so
many controls. First thing I would recommend is check to see if you
have a BIOS update - kindly apply that.

To exclude hardware or BIOS problems, I used a different atom based board
that we had lying around
(other hardware vendor). Both are identical where audio chain is concerned
(intel US15W SCH and ALC888 codec)
Ossplay, osstest and ossmix have exactly the same behaviour.

Post by Dev Mazumdar

SOmething is wrong because the device is showing gray1 and
gray2 jacks.
I wonder if it's finding the docking station codec as well as the
front panel codec. I guess there's also an HDMI codec.
The MIX controls are basically Summing widgets that take the sum of
all the outputs and inputs as the input.

If the mixer takes also the outputs as input, it can explain why I have a
periodic noise on top of my signal.
How do I break this loopback ?
Where does the mixer output the sum of all signals to ? Straight to the DAC
or is the mixer after the DAC?

Post by Dev Mazumdar

This may need some special parsing. Try to compile the

mixgen2.c file

in utils directory and generate the parsed output (see
http://opensound.hg.sourceforge.net/hgweb/opensound/opensound/
file/44441f68d702/utils/mixgen2.c)

I attached the output of the mixgen command to the mail.
The results are interesting : it mentions spdif in and outs
and I do have 2 physical digital jacks on my board, but there
are no mixcontrols in the general mixer to mute them. This
could be the reason (or part of it .. ) that when osstest
tests the spdif that I hear it on the analog jack ...

I tried looking on the OSS4 webpages for pointers on how to customize the
parsing,
but couldn't find any.
Please advise,
Sven
_______________________________________________
oss-devel mailing list
http://mailman.opensound.com/mailman/listinfo/oss-devel

[S***@be.thalesgroup.com]

-----Original Message-----
Hannu Savolainen
Sent: 28 February, 2011 23:02
To: Discussion mailing list for developers of OSS
Subject: Re: [oss-devel] Intel atom SCH support
Hi,
BIOS update cannot fix this kind of problems. Many codecs
just have too many controls that have redundant
functionality. Hand coding is probably the only way to get
the mixer to work properly.
Hannu

Hello,

The OSS support for intel SCH hdaudio is very important for the company I
work for,
so we have no problem of doing the handcoding/tuning to get it working and
give the changes to the community.

I have a couple of boards here that I can use, so access to hardware is not
a problem.

As for the code itself, I've been churning embedded C for over 10 years now,
so the actual coding is not a problem either.

However, I will need a few pointers as to the HOW w.r.t. the inside of OSS.

For instance, a small explanation about those widgets the mixgen mentions
and how to interprete and customize an oss codec driver would help.

Another thing I would like to identify is whether the problems I face now
are related to the atom chipset hdaudio controller or to the realtek ALC888
codec which IIRC is allready supported by OSS. I presume it is the former,
but I'd like to make sure first ...


Thanks a lot,

Sven

[Hannu Savolainen]

Hi,

The controller part doesn't require any work. All controllers work
exactly in the same way.

However codecs are different. To make things even worse motherboard
manufacturers have complete freedom to decide which I/O pin they connect
the jacks and other audio inputs and outputs. It is not enough to write
just one mixer driver for each codec. This needs to be done by hand for
every single motherboard (unless there are boards that have the pins
assigned in the same way).

The mixgen.c can be used to create a skeleton of a mixer driver. Then
the result can be fine tuned by using trial and error approach.

Hannu
---

Post by S***@be.thalesgroup.com

-----Original Message-----
Hannu Savolainen
Sent: 28 February, 2011 23:02
To: Discussion mailing list for developers of OSS
Subject: Re: [oss-devel] Intel atom SCH support
Hi,
BIOS update cannot fix this kind of problems. Many codecs
just have too many controls that have redundant
functionality. Hand coding is probably the only way to get
the mixer to work properly.
Hannu

Hello,
The OSS support for intel SCH hdaudio is very important for the company I
work for,
so we have no problem of doing the handcoding/tuning to get it working and
give the changes to the community.
I have a couple of boards here that I can use, so access to hardware is not
a problem.
As for the code itself, I've been churning embedded C for over 10 years now,
so the actual coding is not a problem either.
However, I will need a few pointers as to the HOW w.r.t. the inside of OSS.
For instance, a small explanation about those widgets the mixgen mentions
and how to interprete and customize an oss codec driver would help.
Another thing I would like to identify is whether the problems I face now
are related to the atom chipset hdaudio controller or to the realtek ALC888
codec which IIRC is allready supported by OSS. I presume it is the former,
but I'd like to make sure first ...
Thanks a lot,
Sven
_______________________________________________
oss-devel mailing list
http://mailman.opensound.com/mailman/listinfo/oss-devel

[Dev Mazumdar]

Hi,


There's another program called snoopy
http://opensound.hg.sourceforge.net/hgweb/opensound/opensound/file/bb8f190c9817/utils/snoopy.c

That will print out all the widgets.

see if you can compare the output from ALSA on Linux 2.6. You can look
at cat at the codec0 under /proc/asound and see what it has set for all
the verbs and then you can write a dedicated OSS mixer using similar
settings.


regards
Dev

---------------------------------------------------
4Front Technologies, Inc.
http://www.opensound.com
9826 Beverlywood Street, Los Angeles, CA 90064, USA
Tel: [phone] Fax: [phone]
---------------------------------------------------

Post by S***@be.thalesgroup.com

-----Original Message-----
Hannu Savolainen
Sent: 28 February, 2011 23:02
To: Discussion mailing list for developers of OSS
Subject: Re: [oss-devel] Intel atom SCH support
Hi,
BIOS update cannot fix this kind of problems. Many codecs
just have too many controls that have redundant
functionality. Hand coding is probably the only way to get
the mixer to work properly.
Hannu

Hello,
The OSS support for intel SCH hdaudio is very important for the company I
work for,
so we have no problem of doing the handcoding/tuning to get it working and
give the changes to the community.
I have a couple of boards here that I can use, so access to hardware is not
a problem.
As for the code itself, I've been churning embedded C for over 10 years now,
so the actual coding is not a problem either.
However, I will need a few pointers as to the HOW w.r.t. the inside of OSS.
For instance, a small explanation about those widgets the mixgen mentions
and how to interprete and customize an oss codec driver would help.
Another thing I would like to identify is whether the problems I face now
are related to the atom chipset hdaudio controller or to the realtek ALC888
codec which IIRC is allready supported by OSS. I presume it is the former,
but I'd like to make sure first ...
Thanks a lot,
Sven
_______________________________________________
oss-devel mailing list
http://mailman.opensound.com/mailman/listinfo/oss-devel