> You should look in /proc/asound instead: aplay requires quite a lot of > things to be working, /proc/asound will exist even when only ALSA is > present. Please don't get me wrong here. I AM **NOT** using the DEPRECATED OSS drivers. (period) I AM USING THE ALSA OSS LAYER - ONLY ALSA. and they all load and run properly. just fine. Sequencer, clock, etc... OSS devices ( in /dev ) can be opened (via alsa-lib open func) but HW devices ( in /dev and /dev/snd ) are failing (via same alsa-lib open func) ** ALL DEVICE NODES ARE FIXED ** ** INDEED THIS SYSTEM DOES NOT REQUIRES UDEV AT ALL** ** UDEV IS TOTALLY AND COMPLETELY USELESS in this system** **BUT** for the sake of testing I DID USED IT a bit.. BUT KEEPING THE /dev tree INTACT and EXACTLY THE SAME as it is/was (perms/nodes,etc) As today seems that a lot of folks are biased towards the UDEV thing.... I tried... > udev actually kicks in before you even get into single user, a system > using udev uses it to discover almost all the hardware. The major > distros use it because it's more reliable. Even my RaspberryPi uses it. I see this situation... but **IF** you use UDEV to populate /dev. This /dev nodes are FIXED. UDEV indeed makes no diff **UNLESS** some changes are required and RELIES ON UDEV TO DO SO. I am not aware of any... if anyone can identify that, great... That would be another test frontier... Thanx ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d _______________________________________________ Alsa-user mailing list Alsa-user@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-user
