I have a new Dell PowerEdge T110 workstation to replace the old T105. Both of
them lack any proper sound hardware so I've got USB speakers.
Some time in the process of replacing the system or the monitor (which is a
USB hub and thus changes USB device assignment) sound stopped working in KDE.
It seems that the main problem is that there is some sort of sound hardware
detected on the motherboard (maybe the built in PC speaker) which causes the
real sound hardware to be registered as ALSA device 1.
So far the only way I've discovered to make things work is to make the
following sym-links to make the USB sound hardware be device 0.
# ls -l /dev/snd
total 0
drwxr-xr-x. 2 root root 60 Dec 9 20:49 by-id
drwxr-xr-x. 2 root root 80 Dec 9 20:49 by-path
lrwxrwxrwx. 1 root root 9 Dec 18 00:05 controlC0 -> controlC1
crw-rw---T. 1 root audio 116, 3 Dec 9 20:49 controlC1
crw-rw---T. 1 root audio 116, 5 Dec 9 20:49 hwC0D0
lrwxrwxrwx. 1 root root 8 Dec 18 00:09 pcmC0D0p -> pcmC1D0p
crw-rw---T. 1 root audio 116, 4 Dec 9 20:49 pcmC0D3p
crw-rw---T. 1 root audio 116, 2 Dec 18 00:09 pcmC1D0p
crw-rw---T. 1 root audio 116, 1 Dec 9 20:49 seq
crw-rw---T. 1 root audio 116, 33 Dec 9 20:49 timer
Is there a way that I can reserve device 0 for the USB device? It needs to be
reserved because the motherboard hardware is detected before the USB bus is
scanned - if the monitor is even turned on when the system is booted.
Is there a way I can make the system just ignore the motherboard device and
have only 1 ALSA card? There's only one thing that can ever be useful so it
seems best to make it the only recognised card in the system.
Thanks
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
I have an iso image of the Fedora 20 install DVD, but when I try to use
it I get this:
> fedup -v --iso Fedora-20-x86_64-DVD.iso --network 20
usage: fedup <SOURCE> [options]
fedup: error: argument --iso: invalid isofile value:
'Fedora-20-x86_64-DVD.iso'
>
I wrote this exact iso file to a stick. mounted it, and used the
"--device DEV"
option, and successfully ran the upgrade, so I would like to know for
the future what does the "--iso" option really want?
Hello,
I'm curious if anyone could recommend Linux friendly hardware suppliers
in Melbourne?
We're a small/medium business, and I often get the feeling that server,
network and storage vendors want to push non-FOSS platforms and are
unable to advise on integration with existing FOSS systems.
Would make a nice change to have a vendor who understood the merits of
Linux KVM, DRBD, Amanda backup, etc.
Cheers,
Rob.
Hi folks,
Anyone got any recommendations or experiences with Haswell laptops
running Linux yet?
Thinking that it might be time to refresh my work laptop and a Haswell
Ultrabook could be quite enticing..
cheers!
Chris
--
Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
Hi everyone,
My brother is looking for a new laptop.
He uses it for generally pretty basic stuff - multimedia playback, web
browsing, a bit of gimp.
His criteria is:
- Ideally 15" screen, 14" would be acceptable
- 2.5kg or lower
- ideally battery lasting through a day at uni
- running ubuntu
Please reply all to include him in the discussion.
Cheers,
Bianca
Hi all,
I thought I would take kdeconnect-kde for a spin, I used the
OpenSUSE13.1 version and installed the Android App on my Samsung Galaxy
s2. My phone is connected to the WiFi network but the desktop can't see
it and vice versa. Has anyone else used this, yet, and do I need to
register my phone name in my desktop hosts file for this to work?
In theory, when I walk in the door at home my computer should
automatically link with my phone. At the moment they are not on
speaking terms.
Cheers
Andrew Greig
zlinw(a)mcmedia.com.au writes:
Oops for got the Subject line
Russell Coker said,
> Is there a way that I can reserve device 0 for the USB device? It needs
> to
> be reserved because the motherboard hardware is detected before the USB
> bus
> is scanned - if the monitor is even turned on when the system is booted.
In theory one can cause ALSA to allocate snd devices to a particular alsa
sound device number, I have though NEVER though in a good number of years
been able to get this to work with any kind of relaibilty.
> Is there a way I can make the system just ignore the motherboard device
> and have only 1 ALSA card? There's only one thing that can ever be
> useful
> so it seems best to make it the only recognised card in the system.
There are two ways one can compile a kernel with only the sound device
driver required present. The second method is simpler than anything else
and does work. Do an lsmod and identify the main module that is loaded for
the offending device then blacklist this module in ....
/etc/modprobe.d/alsa-base-blacklist.conf (in debian anyway)
This prevents the kernel loading the module.
Lindsay
Russell Coker said,
>Is there a way that I can reserve device 0 for the USB device? It needs to
>be reserved because the motherboard hardware is detected before the USB
bus
>is scanned - if the monitor is even turned on when the system is booted.
In theory one can cause ALSA to allocate snd devices to a particular alsa
sound device number, I have though NEVER though in a good number of years
been able to get this to work with any kind of relaibilty.
>Is there a way I can make the system just ignore the motherboard device
>and have only 1 ALSA card? There's only one thing that can ever be useful
>so it seems best to make it the only recognised card in the system.
There are two ways one can compile a kernel with only the sound device
driver required present. The second method is simpler than anything else
and does work. Do an lsmod and identify the main module that is loaded for
the offending device then blacklist this module in ....
/etc/modprobe.d/alsa-base-blacklist.conf (in debian anyway)
This prevents the kernel loading the module.
Lindsay
git beginner here, so forgive me.
As part of change management of a couple hundred servers, we do a regular
'git add .' on a central repository of half a million files, followed by a
bit of munging, then a 'git commit -a -m ...' (rhel5, so 'git -a' is 'git
-A' elsewhere).
'git add .' is very very slow at finding the additions and modifications
(we don't care about the '-u' deletions at this stage, because of the
future munging required) and staging them. I suspect it's actually
staging every single file rather than just changes.
'git status -s' on a freshly changed repository prior to doing any git add
is really quite quick (no, it's not a cold or undersized cache issue), and
finds all additions, deletions and modifications. We could simply pipe
that rather small output to 'git add' and it would be much much quicker at
staging them (er, I think; but also, a bit of a kludge). Any known reason
why git-add would appear to be recursing through the entire tree staging
even unchanged files, and not just acting on the changed files that
git-status obviously can find very quickly? Any missing bit of git magic
I could be applying?
--
Tim Connors
Some time back I was mentioning a problem I was having with the NVidia
closed src driver. Russel Coker made a sugestion I checked out the open src
driver. Now I have had a look at the state of progress on both NVidia and
ATI/AMD cards and the big open src improver is for Radeon R600g driver.
This covers ATI/AMD Radeon HD3000 to 6870 cards, (NOT the 6900 cards these
being covered by the Radeonsi driver).
For the R600g driver benchmarks using 3.11.1 kernel and Mesa 9.2 (both
being in current debian testing) show that 3D apps were running at around
2/3rds of the frame rate as the windows driver. There were plenty of
reports from users saying it was running all linux games with the quality
sliders at max at 60 fps, there being only a single report slower than that
and it said it was smooth and highly playable. All stated the driver was
very stable and one could switch to a kernel console and back to X without
crashing the system.
With kernel 3.12.0 and mesa 10, this of course is fairly new, benchmarks
comparing with windows 7 produced the same results, ie the driver was as
fast as the one on windows.
This is all excellent news for opensource Linux.
Interestingly around 2 years ago when the AMD open source liason officer
was asked if the opensource driver would EVERY get as fast as the then
windows driver he replied it would and would likely end up faster. His
reasons for saying that was he said that the opensource was a far cleaner
and simpler driver than the windows counterpart, not having to worry about
backwards compatibilty and a binary interface to the kernel.
Lindsay
