> Quick query - I'm thinking of buying a machine based on the GIGABYTE
> GA-B75M-D3V mobo, which has an Intel B75 chipset.
>
> I'm hoping it will run linux (specifically Mint Maya) - can anyone say
> please for sure?

I think you need a CPU to actual run the kernel. ;)

What you have to realize is that a motherboard, and especially more
modern latest generation come with lots of peripheral devices
eg on board sound, on board LAN, on board WiFi etc, and one must
check if each of these is supported in the current kernel.

Do you expect readers of this newsgroup to check every feature
on the motherboard for you?

The indication from the Gigabyte web site its-self, which is where
surely you must have checked first, is that there is some Linux
support for this motherboard.

On 25/07/12 15:11, J G Miller wrote:
> On Wednesday, July 25th, 2012, at 14:35:53h +0100, Mike Scott wrote:
>
>> Quick query - I'm thinking of buying a machine based on the GIGABYTE
>> GA-B75M-D3V mobo, which has an Intel B75 chipset.
>>
>> I'm hoping it will run linux (specifically Mint Maya) - can anyone say
>> please for sure?
>
> I think you need a CPU to actual run the kernel. ;)

Cooo!

Core i5 3450 in this case. But I was assuming that anything plugging in
that board would be much the same as regards drivers.

>
> What you have to realize is that a motherboard, and especially more
> modern latest generation come with lots of peripheral devices
> eg on board sound, on board LAN, on board WiFi etc, and one must
> check if each of these is supported in the current kernel.
>
> Do you expect readers of this newsgroup to check every feature
> on the motherboard for you?

Course not! But I was hoping that someone might say 'yes, done that and
it works', or 'no, tried that and gave up'.

Of course. Gigabyte's "Due to different Linux support condition provided
by chipset vendors, please download Linux driver from chipset vendors'
website or 3rd party website" is cryptic to say the least. But hopeful.

> Course not! But I was hoping that someone might say 'yes, done that and
> it works', or 'no, tried that and gave up'.

Yes there is always the possibility that somebody else in the
group has already got one of these boards and tested it with
GNU/Linux.

You would improve the probability of finding somebody else
though if you cross-posted your question not to a UK specific
newsgroup, but to a worldwide news group eg

comp.os.linux.hardware

and perhaps

alt.os.linux

> Of course. Gigabyte's "Due to different Linux support condition provided
> by chipset vendors, please download Linux driver from chipset vendors'
> website or 3rd party website" is cryptic to say the least. But hopeful.

I think it basically means that Gigabyte do not provide any
GNU/Linx software themselves but that the vendors of the onboard
devices most likely do.

To be honest, with the latest Linux kernels you will probably
find the most of, if not all, on board devices are supported "out
of the box", especially with latest distributions such as
Linux Mint. The usual problem are with WiFi devices, but
as this board does not have any, then that does not arise.

> I intend settling for the on-board (or is that on-chip these days???)
> graphics.

I would be a little concerned about that -- the Gigabyte specifications
section for graphics does not actually state which graphics chipset is present.

In the general blurb it mentions "Intel® HD Graphics 4000/2500"
but which one is it? The Intel 4000 or the Intel 2500 which are
two related but different graphics chips.

Considering the UKofGB&NI VAT rate of 20%, I guess the press is not
too bad, but the PSU looks to be rather poor

350w PSU

Have you ever considered building your own machine?

And of course everything depends for what purpose you intend
using the machine -- if it is just for e-mail, web surfing,
maybe document preparation, then it is more than adequate.

> Unfortunately novatech won't be drawn about linux operation.

Machine builders (unless GNU/Linux specific) will rarely
ever say anything about GNU/Linux operation because they
are in the business of selling Micro$oft products.

> It's no great earth-shatterer, but should get some 3d rendering done
> better than my aging Athlon!

3D rendering? I may in error, but I think you would really
need a better video graphics capability than the onboard chip,
whatever it is. Even a low range nVidia (somewhere in the GBP 50 - 150
price range) would be much more appropriate for that type of task.

Other than those points, I would guess that trying to run
Linux Maya 13 on it would have no real problems, other than
the current foibles and bugs inherent to the distribution.
(And yes every distribution comes with them.)

> To be honest, with the latest Linux kernels you will probably
> find the most of, if not all, on board devices are supported "out
> of the box", especially with latest distributions such as
> Linux Mint. The usual problem are with WiFi devices, but
> as this board does not have any, then that does not arise.

That's rather what I hoped - but it's a bit late after buying it.....
But I've just put Mint onto a Revo 3700 very happily with a sound/hdmi
hiccup (resolved) and the wifi working (once I'd read the box label
about the chipset (!!)) so not all is black.

>
>> I intend settling for the on-board (or is that on-chip these days???)
>> graphics.
>
> I would be a little concerned about that -- the Gigabyte specifications
> section for graphics does not actually state which graphics chipset is present.
>
> In the general blurb it mentions "Intel® HD Graphics 4000/2500"
> but which one is it? The Intel 4000 or the Intel 2500 which are
> two related but different graphics chips.

I've had my head in the sand for too many years; technology's shifted a
couple of gears in the meantime. But it looks as though the graphics is
in the processor - in this case, the i5-3450 integrates the 2500 graphics.

>
>> FWIW the particular machine I'm looking at is at
>> http://www.novatech.co.uk/pc/range/novatechlifenti03.html>
> Considering the UKofGB&NI VAT rate of 20%, I guess the press is not
> too bad, but the PSU looks to be rather poor
>
> 350w PSU
>
> Have you ever considered building your own machine?

Yes, but it's rarely seemed cost-effective though. I've a mini-itx
machine I pretty well had to assemble from scratch to meet my
requirements, and a couple of bare-bones type boxes (not that I'd go
that route again).

>
> And of course everything depends for what purpose you intend
> using the machine -- if it is just for e-mail, web surfing,
> maybe document preparation, then it is more than adequate.

Vastly so :-)

....

>> It's no great earth-shatterer, but should get some 3d rendering done
>> better than my aging Athlon!
>
> 3D rendering? I may in error, but I think you would really
> need a better video graphics capability than the onboard chip,
> whatever it is. Even a low range nVidia (somewhere in the GBP 50 - 150
> price range) would be much more appropriate for that type of task.

Now there's a point. Running blender on my 750Mb Athlon 2.4+ is an
experience best missed (although it does run); /Any/ hardware these days
will be better :-) That said, it's really only pottering, nothing serious.

But does something like blender use the cpu, or the gpu? Or use
whatever's available? I really have no idea :-{ It is though partly why
I was looking at the 4-core processor, on the assumption that would
speed things up. If programs like blender use a gpu, I might be better
off with an i3 2-core processor, and buy a decent graphics card with the
price difference. I must check.

>
> Other than those points, I would guess that trying to run
> Linux Maya 13 on it would have no real problems, other than
> the current foibles and bugs inherent to the distribution.
> (And yes every distribution comes with them.)

Also DVI supports higher refresh rates than the current HDMI
specification which is 60 Hz maximum if I recall correctly.

> Yes, but it's rarely seemed cost-effective though.

All depends on how fussy or not you are over the components ;)

> and a couple of bare-bones type boxes (not that I'd go
> that route again).

Can you elaborate as to why not? -- this would be useful information.

> But does something like blender use the cpu, or the gpu?

All depends. ;) You have your graphics card and your
Xorg module for that card and then for the "gpu" processing,
if available on the hardware, you need another piece of software.

In the case of nVidia cards, this is called "CUDA". There is a
cuda library and applications have to be compiled with it,
and so use it if the feature is detected on the video card.

And in the case of blender, good news --

QUOTE

Doc:2.6/Manual/Render/Cycles/GPU Rendering - BlenderWiki

NVidia CUDA is supported for GPU rendering with NVidia
graphics cards. We support graphics cards starting from GTX 2xx

UNQUOTE

I am ignorant as to whether or not any Intel on board chips
offer GPU processing, but I doubt it, and again, I am guessing
but I do not think the equivalent GPU processing for AMD/ATI
is available under Linux or that any GNU/Linux programs can
take advantage of it.

> I was looking at the 4-core processor, on the assumption that would
> speed things up. If programs like blender use a gpu, I might be better
> off with an i3 2-core processor, and buy a decent graphics card with the
> price difference. I must check.

Well I did mention that a good (but not hyper-expensive) graphics
might be worthwhile, but would cutting back to a 2 core processor
be a false economy in the long run?

Anyways I hope the points above will provide you with something useful
to start investigating to help you in your decision as to what
is most appropriate for your present and future needs.

On 2012-07-27, TheOldFellow <theold...@gmail.com> wrote:
> On Wed, 25 Jul 2012 14:35:53 +0100, Mike Scott wrote:
>
>> Quick query - I'm thinking of buying a machine based on the GIGABYTE
>> GA-B75M-D3V mobo, which has an Intel B75 chipset.
>>
>> I'm hoping it will run linux (specifically Mint Maya) - can anyone say
>> please for sure?
>>
>> Thanks.
>
> I have had no problems whatsoever with Novatech machines and Linux, and
> I've bought 10 or so over the years for myself and others.

I change Motherboards more often than many people, I never worry about the
will Linux work question. For they always have.

The exception, was when I test drove an "older" version on a brand new
motherboard. The network card was not recongised.

The hardware and software improvement paths go on in parallel. Sometimes you
do manage to find a void. Chalk it up if you do.

On 2012-07-26, J G Miller <miller@yoyo.ORG> wrote:
> On Thursday, July 26th, 2012, at 12:08:31h +0100, Mike Scott wrote:
>
>> Course not! But I was hoping that someone might say 'yes, done that and
>> it works', or 'no, tried that and gave up'.
>
> Yes there is always the possibility that somebody else in the
> group has already got one of these boards and tested it with
> GNU/Linux.
>
> You would improve the probability of finding somebody else
> though if you cross-posted your question not to a UK specific
> newsgroup, but to a worldwide news group eg
>
> comp.os.linux.hardware
>
> and perhaps
>
> alt.os.linux
>
>> Of course. Gigabyte's "Due to different Linux support condition provided
>> by chipset vendors, please download Linux driver from chipset vendors'
>> website or 3rd party website" is cryptic to say the least. But hopeful.
>
> I think it basically means that Gigabyte do not provide any
> GNU/Linx software themselves but that the vendors of the onboard
> devices most likely do.

In an open source world that is not too important. What is, that the
MB/harware manufacture gives the information needed so that the open Source
Community can write the required software.

Gordon <Gor...@clear.net.nz> wrote:
> In an open source world that is not too important. What is, that the
> MB/harware manufacture gives the information needed so that the open Source
> Community can write the required software.

Indeed, and when the vendor offers drivers to download from their website
they're almost certainly not what you want. Your distro should already have
support in it, and if it doesn't the latest mainline kernel should.
Installing the manufacturer's clumsy .zip and building a kernel with it is
the last resort.

In article <jurefr$eh4$3...@dont-email.me>, J G Miller wrote:
>> Of course. Gigabyte's "Due to different Linux support condition provided
>> by chipset vendors, please download Linux driver from chipset vendors'
>> website or 3rd party website" is cryptic to say the least. But hopeful.
>
> I think it basically means that Gigabyte do not provide any
> GNU/Linx software themselves but that the vendors of the onboard
> devices most likely do.

I read it more as "if the distro you're using doesn't support some part of
the functionality of the board then try downloading drivers from the
chipset vendors". Unfortunately that's the sort of thing motherboard
vendors tend to say about ALL their boards, so it can't really be taken as
any evidence that the manufacturer has actually thought about linux support
for any given board.

However, it's fair to say that the kernel developers *do* provide support
for most common chipsets within a few months of their release; so almost
everything does work, these days.

On 26/07/12 17:12, J G Miller wrote:
> On Thursday, July 26th, 2012, at 16:09:32h +0100, Mike Scott wrote:
>
>> I know; thanks for pointing it out. Not fussed about this.
>
> Also DVI supports higher refresh rates than the current HDMI
> specification which is 60 Hz maximum if I recall correctly.
>
>> Yes, but it's rarely seemed cost-effective though.
>
> All depends on how fussy or not you are over the components ;)
>
>> and a couple of bare-bones type boxes (not that I'd go
>> that route again).
>
> Can you elaborate as to why not? -- this would be useful information.

(Celeron systems with Foxconn mobos, both seemed a bit slow in the disk
i/o department; but maybe that's just my fancy.)

>
>> But does something like blender use the cpu, or the gpu?
>
> All depends. ;) You have your graphics card and your
> Xorg module for that card and then for the "gpu" processing,
> if available on the hardware, you need another piece of software.
>
> In the case of nVidia cards, this is called "CUDA". There is a
> cuda library and applications have to be compiled with it,
> and so use it if the feature is detected on the video card.
> And in the case of blender, good news --

Thanks for pointing that out. I wasn't at all aware of the CUDA
libraries; they look worth remembering. However, a board that would be
useful would have, apparently, to be a GTX5xx or better; decidedly
pricey compared to this particular machine I'm looking at.

Incidentally, on the cusp of placing an order, I came across this
caveat, pretty hot off the press:

"The Ivy Bridge issue ... the wrong thread count for the pixel shader
was set for Ivy Bridge HD 2500 (GT1) hardware within [Intel's]
open-source X.Org driver. The invalid number of threads for the pixel
shader in turn caused this lower-end Ivy Bridge hardware to hang. The
2.20.2 update fixes this for Intel HD 2500 system owners. "

They use wormhole delivery and send the goods out before you've ordered them.
Mostly it works out just right but very occasionally the wormhole goes past the
wrong galaxy and could be as much as an hour late :p

I'm sure it's nothing fundamental, but I'm finding it impossible to get
sound out of the rear sound socket. Some config problem, I'm sure,
between pulse and alsa; but I can't spot it. Front headphone socket is
OK, bar a few low-level weird tweedly sounds. Rather similar to an HDMI
sound problem I had on a Revo: but guess who forgot to write down the
workings for the solution to that one :-{ :-{

> I'm sure it's nothing fundamental, but I'm finding it impossible to get
> sound out of the rear sound socket. Some config problem, I'm sure,
> between pulse and alsa; but I can't spot it. Front headphone socket is
> OK, bar a few low-level weird tweedly sounds. Rather similar to an HDMI
> sound problem I had on a Revo: but guess who forgot to write down the
> workings for the solution to that one :-{ :-{

Maybe I should do a webpage on "How to get the sound output of your choice
working via ALSA when the system has been infected with PulseAudio." ;->
Although I'm sure many already exist...

If you look back though group postings searching for 'alsa' you may find
the earlier posts on this general topic.

On 06/08/12 15:06, Jim Lesurf wrote:
> In article <jvo3qi$fge$1...@dont-email.me>, Mike Scott
> <usenet.14@scottsonline.org.uk.invalid> wrote:
>
>> I'm sure it's nothing fundamental, but I'm finding it impossible to get
>> sound out of the rear sound socket. Some config problem, I'm sure,
>> between pulse and alsa; but I can't spot it. Front headphone socket is
>> OK, bar a few low-level weird tweedly sounds. Rather similar to an HDMI
>> sound problem I had on a Revo: but guess who forgot to write down the
>> workings for the solution to that one :-{ :-{
>
> Maybe I should do a webpage on "How to get the sound output of your choice
> working via ALSA when the system has been infected with PulseAudio." ;->
> Although I'm sure many already exist...
>
> If you look back though group postings searching for 'alsa' you may find
> the earlier posts on this general topic.
>
> Slainte,
>
> Jim
>

Something singularly elementary would be very handy....

After a whole morning of bashing my head against the wall, I realised
that (a) I needed to make a .asoundrc (I gleaned enough off the net in
dribs and drabs to make this), and (b) I was fiddling with the wrong
volume control in alsamixer ("Front" rather than "PCM" -- with only 2
channels, "Front" is a bit of a tautology!). I knew it would be
something stupidly simple......

But .asoundrc really could do with some tutorials written for it. I
guess I'm not qualified :-)

> > Maybe I should do a webpage on "How to get the sound output of your
> > choice working via ALSA when the system has been infected with
> > PulseAudio." ;-> Although I'm sure many already exist...

> Something singularly elementary would be very handy....

I haven't done it (as yet) because I've assumed other pages would be OK,
and because I get diverted onto other matters. I also live in faint hope
that the people who make distros will finally deal with this issue and
either make Pulse work *correctly* or admit defeat and let people simply
use alsa.

> After a whole morning of bashing my head against the wall, I realised
> that (a) I needed to make a .asoundrc (I gleaned enough off the net in
> dribs and drabs to make this), and (b) I was fiddling with the wrong
> volume control in alsamixer ("Front" rather than "PCM" -- with only 2
> channels, "Front" is a bit of a tautology!). I knew it would be
> something stupidly simple......

> But .asoundrc really could do with some tutorials written for it. I
> guess I'm not qualified :-)

Alas, although there are tutorials, they tend to go on to cover all kinds
of specific cases, so the basic requirements tend to become buried in
things like "how to get two stereo cards to work together to give me
surround sound." Which most people won't care about!

There are really just a few key points for most ordinary stereo use.

1) Put a simple set of instructions into an .asoundrc file to redefine the
'default' settings.

Ignore the maths and diagrams at the start and just scroll down to the 'A
Practical Example' section. Tha shows an .asounrc file with a default
setting and a couple of (optional) 'plugs'. In this case it includes a line
on the format in the default. But most people won't need that if they are
using a normal internal device.

So the basic .asounrc content you need is usually something like

pcm.!default {
type plug
slave {
pcm "hw:2"
channels 2
}
}

for stereo. (You may not need the 'channels 2' line, but it should do no
harm if you want stereo.)

But will probably need to change the "hw:2" to some other numbers
appropriate for the 'card' and 'device' you want to use. To investigate,
use the command

aplay -l

(lower case 'L' after the '-')

That lists the card and device numbers. If you then want to use card n that
has a device m just put those values in as the m and n in the line

pcm "hw:m,n"

The command

aplay -L

(upper case 'L' now)

gives more info on each card/device. This can be useful to check if it can
play the kind of file you are sending to it. And if you want to play
'surround' like 5.1 or 7.1 it may tell you which 'device' of the 'card' is
the one you need. Here I assume stereo as that has been my interest, so it
is what I know best.

Test using stereo wav files ripped from a CD. This is to ensure 44k/16bit
stereo which I'd expect most cards/devices to be happy with. A backup is to
try 48k/16bit stereo.[1] If you try low sample rate mono wave files they
may not work because the hardware can't make sense of them when sent
directly.

In general you should find you can then play audio *without* having to go
via the 'mixers' at all, and can ignore their settings. But if your card
can't cope with a range of sampling rates you may have to evoke the mixer
by adding a line forcing the format (like the example on the page that
forces the alsa mixer to convert all streams to 24 bit in 32 bit word
format.) However !default overrules all previous alsa settings, so by using
this you should not have to furtle about trying to fix all the incorrect
settings that the install may have imposed.

I guess I should do an explicit page on this sometime...

HTH

Slainte,

Jim

[1] Either ripped from a DVD or use sox to create this for some other file.

Not knowing about your HDMI hardware I can't say how many of the 'dmixer'
values you give are actually needed. e.g. I'd expect HDMI to accept 48k and
so it should not be necessary to force everything to be converted to 44k.

>> It seems I was too hopeful - something's still wrong. It stopped working
>> after a reboot - it seems the builtin and the hdmi sound "cards" have
>> swapped places: I had to change
>
>> pcm "hw:1,0" into pcm "hw:0,0"
>
>> in the pcm.dmixer spec. to make it work today.
>
> I think you'd need to find out if that will remain. If the system boots
> with a different assignment you may need to fix that problem.
>
> Alternatively, you may be able to be more specific wrt designation. But I'm
> not sure how at present. What does 'aplay -L' give you?

It's a bit long!

With a bit^Wlot of guesswork, I've changed the pcm line above to be
pcm "hw:PCH,0"

Which seems to work, and as ' pcm "hw:xxPCH,0" ' fails horribly, I
assume it's reasonable to leave.

<usenet.14@scottsonline.org.uk.invalid> wrote:
> On 07/08/12 13:52, Jim Lesurf wrote: .....
> >> It seems I was too hopeful - something's still wrong. It stopped
> >> working after a reboot - it seems the builtin and the hdmi sound
> >> "cards" have swapped places: I had to change
> >
> >> pcm "hw:1,0" into pcm "hw:0,0"
> >
> >> in the pcm.dmixer spec. to make it work today.
> >
> > I think you'd need to find out if that will remain. If the system
> > boots with a different assignment you may need to fix that problem.
> >
> > Alternatively, you may be able to be more specific wrt designation.
> > But I'm not sure how at present. What does 'aplay -L' give you?

> It's a bit long!

> With a bit^Wlot of guesswork, I've changed the pcm line above to be pcm
> "hw:PCH,0"

> Which seems to work, and as ' pcm "hw:xxPCH,0" ' fails horribly, I
> assume it's reasonable to leave.

Yes, I think so. However I think it means you are going via the mixer. Did
not alternatives like NVidia,X or HDA NVidia,X - where X was a number -
work?

The advantage of the 'Direct hardware device" choices is that the stream is
sent with no risk of being tampered with. But you may find the direct
routes to hardware are picky about the format (sample rate, etc). Going via
the mixer lets the software handle any conversions the hardware says it
needs. In some ways safer, but can cause the sound to be altered or lost
for other reasons.

Can't be sure, though, as I don't use HDMI and haven't encountered the
problem you describe of the numberings changing after a new bootup. I
always send direct to an external USB 'card' (DAC).

> It really would be good to have a proper tutorial somewhere :-(

Agreed. The snag is that a simple tutorial can end up omitting the key
wrinkles that someone needs. OTOH Complex ones end up covering so many
'rare cases' that they bewilder all but the most determined reader!

However, as you have seen, the advantage of 'aplay -L' over 'aplay -l' is
that it shows you an alternative way to specify which card/device to
choose, and also tells you which devices are 2-channel, which are
multichannel, etc. So make it easier to spot the one you wish.

On 08/08/12 10:32, Jim Lesurf wrote:
> In article <jvrf2d$3l7$1...@dont-email.me>, Mike Scott
> <usenet.14@scottsonline.org.uk.invalid> wrote:
>> On 07/08/12 13:52, Jim Lesurf wrote: .....
>>>> It seems I was too hopeful - something's still wrong. It stopped
>>>> working after a reboot - it seems the builtin and the hdmi sound
>>>> "cards" have swapped places: I had to change
>>>
>>>> pcm "hw:1,0" into pcm "hw:0,0"
>>>
>>>> in the pcm.dmixer spec. to make it work today.
>>>
>>> I think you'd need to find out if that will remain. If the system
>>> boots with a different assignment you may need to fix that problem.
>>>
>>> Alternatively, you may be able to be more specific wrt designation.
>>> But I'm not sure how at present. What does 'aplay -L' give you?
>
>> It's a bit long!
>
>> With a bit^Wlot of guesswork, I've changed the pcm line above to be pcm
>> "hw:PCH,0"
>
>> Which seems to work, and as ' pcm "hw:xxPCH,0" ' fails horribly, I
>> assume it's reasonable to leave.
>
> Yes, I think so. However I think it means you are going via the mixer. Did
> not alternatives like NVidia,X or HDA NVidia,X - where X was a number -
> work?

HDMI is for the future - I'll settle for the built-in card for now. (For
one thing, I need the lead to plug into my raspberry pi :-)

I'm happy enough going via the mixer for now; thanks.

>
> The advantage of the 'Direct hardware device" choices is that the stream is
> sent with no risk of being tampered with. But you may find the direct
> routes to hardware are picky about the format (sample rate, etc). Going via

Yes, I found that the hard way.

> the mixer lets the software handle any conversions the hardware says it
> needs. In some ways safer, but can cause the sound to be altered or lost
> for other reasons.

In this case if it sounds right it is right. Although if I never need to
plug in the 24-bit a/d/a sitting beside me, that may change!

>
> Can't be sure, though, as I don't use HDMI and haven't encountered the
> problem you describe of the numberings changing after a new bootup. I
> always send direct to an external USB 'card' (DAC).
>
>> It really would be good to have a proper tutorial somewhere :-(
>
> Agreed. The snag is that a simple tutorial can end up omitting the key
> wrinkles that someone needs. OTOH Complex ones end up covering so many
> 'rare cases' that they bewilder all but the most determined reader!

I suspect the problem is that those who understand can't remember or see
the elementary problems, while those with the elementary problems can't
fix 'em. So no-one gets to write the book :-)

> In article <jvp16h$v8d$1...@dont-email.me>, Mike Scott
> <usenet.14@scottsonline.org.uk.invalid> wrote:
>> On 06/08/12 15:06, Jim Lesurf wrote:
>
>> >
>> > Maybe I should do a webpage on "How to get the sound output of your
>> > choice working via ALSA when the system has been infected with
>> > PulseAudio." ;-> Although I'm sure many already exist...
>
>
>> Something singularly elementary would be very handy....
>
> I haven't done it (as yet) because I've assumed other pages would be OK,
> and because I get diverted onto other matters. I also live in faint hope
> that the people who make distros will finally deal with this issue and
> either make Pulse work *correctly* or admit defeat and let people simply
> use alsa.
>

Like you I suffered for a few years from pulseaudio issues until I installed
Mageia 2. For the first time in my 'Linux life' (about 9 years)
everything on my home-build worked, including pulseaudio.

Immediately prior to that I was testing PCLinuxOS x86_64 test05 and lovely
though it was, It had too many glitches to keep using it as my main working
machine, particularly with sound.