Re: [Dng] sugestion apulse as pulseaudio replcement

2015-01-23 Thread Joel Roth
Steve Litt wrote:
 Guys, in the past I've tried to get Jack running about four or five
 times, and never succeeded. This included the sound studio version of
 Ubuntu. I'm sure that Jack is perfect for the dedicated sound
 enthusiast, but for the average guy, Jack just might be the only thing
 that could cause more failure than Pulse. Jack is very, very
 complicated.

Steve,

I think you confuse your bad luck in getting started with
Jack being complicated.

If you have ALSA working, and Pulse Audio is not running,
it is very simple to get sound from Jack.

1) start jackd
2) test play some sound, e.g. ecasound -i test.wav -o jack,system

Having JACK serve transparently as the back end with ALSA or
Pulse Audio virtual devices available for client programs 
*is* more complicated.

Jack is most useful in music production, when you want to
connect multiple audio applications together.

I don't run it for routine listening, but you can, if your
applications support it or you use some compatibility layer
over it.

Will be happy to help you, if you need it. Just post to
the appropriate list. Linux Audio User is the best.

Cheers,

Joel

 
 SteveT
 
 Steve Litt*  http://www.troubleshooters.com/
 Troubleshooting Training  *  Human Performance
 
 ___
 Dng mailing list
 Dng@lists.dyne.org
 https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

-- 
Joel Roth
  

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


Re: [Dng] TPM

2015-01-23 Thread Hendrik Boom
On Tue, Dec 23, 2014 at 10:34:25PM +0100, Dr. Nikolaus Klepp wrote:
 Am Dienstag, 23. Dezember 2014 schrieb John Morris:
  
  And yes, putting the thing in hardware does enhance security in ways
  software alone simply can't.
  
 
 … and if you believe that, I have a bridge to sell you.

Doing TPM in hardware can make it harder for malicious software to 
replace it with a fake.  After that, there's the big issue of what is 
to be considered malicious. The viewpoints of manufacturers, OS 
designers, DRM practitioners and users are very different.

-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


Re: [Dng] libsysdev preview

2015-01-23 Thread Isaac Dunham
On Fri, Jan 23, 2015 at 10:57:39PM +0100, k...@aspodata.se wrote:
 Isaac Dunham:
  On Sun, Jan 18, 2015 at 01:11:15PM +0100, k...@aspodata.se wrote:
 ...
   Mesa uses the name sysfs, which might be better than sysdev.
   The following two might be a good start:
   
   $ grep ^sysfs src/loader/loader.c 
   sysfs_get_pci_id_for_fd(int fd, int *vendor_id, int *chip_id)
   sysfs_get_device_name_for_fd(int fd)
   
and
   
   dev_node_from_fd(int fd, unsigned int *maj, unsigned int *min)
 ...
  Optimally, the API will be simple enough that developers then say
  And why aren't we using this *instead* of libudev?
 
 If I get some time over I'd like to try  replacing mesa's routines with
 libsysdev.

Mesa's internal --enable-sysfs is essentially equivalent to libsysdev.
(It was actually the inspiration for what I've written.)


  There's a basic example at util/devinfo.c, and the header has comments
  tersely explaining what inputs each function takes.
 
 devinfo doesn't handle partitions ?
 
 $ devinfo /dev/sda
 /sys//devices/pci:00/:00:13.1/:03:06.0/ata1/host0/target0:0:0/0:0:0:0/block/sda/device
 $ devinfo /dev/sda1
 $

A partition has no device link; there's nothing you get from sysfs
besides this is partition 'n', here's the alignment, here's where it
starts and ends, and by the way here's a bunch of stats about how much
use it's seen this boot.
The device link contains information like the driver in use, modalias,
model, vendor, and a whole bunch of other things; and everything I was
after was in the device link.

If it's meaningful, I can change this behavior; but that *will* 
break the trick I mention -
cat `devinfo /dev/input/node`/name
depends on going into .../device

Or I could add an option to just get the DEVPATH.

  It builds with make (no ./configure).
  It will build and install into /usr/{bin,lib,include} by default.
 
 You can use:
 
 PREFIX=/usr/local make
 PREFIX=/usr/local make install
 
 or similar to make it install in your preferred dir.

For what it's worth, I went to a bit of effort to ensure that PREFIX,
DESTDIR, LIBDIR, and so forth do not change anything before 
make install.

  On debian, devuan, and related distros, you will need to install with:
  make LIBDIR=/usr/lib/$TRIPLET install
  On non-pure64 64-bit installs of other distros, you will need to set
  LIBDIR to point to the appropriate directory (lib32 or lib64).
 
 Works fine on a pure 32-bit debian.

Installing directly in /usr/lib will work, but for packaging multiarch
is important.

Thanks,
isaac Dunham
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


Re: [Dng] libsysdev preview

2015-01-23 Thread karl
Isaac Dunham:
 On Fri, Jan 23, 2015 at 10:57:39PM +0100, k...@aspodata.se wrote:
  Isaac Dunham:
   On Sun, Jan 18, 2015 at 01:11:15PM +0100, k...@aspodata.se wrote:
  ...
Mesa uses the name sysfs, which might be better than sysdev.
The following two might be a good start:

$ grep ^sysfs src/loader/loader.c 
sysfs_get_pci_id_for_fd(int fd, int *vendor_id, int *chip_id)
sysfs_get_device_name_for_fd(int fd)

 and

dev_node_from_fd(int fd, unsigned int *maj, unsigned int *min)
  ...
   Optimally, the API will be simple enough that developers then say
   And why aren't we using this *instead* of libudev?
  
  If I get some time over I'd like to try  replacing mesa's routines with
  libsysdev.
 
 Mesa's internal --enable-sysfs is essentially equivalent to libsysdev.
 (It was actually the inspiration for what I've written.)

Ok, I'll see if I do it or not, but I thought a patch agains mesa could
be a leverage for the lib.

   There's a basic example at util/devinfo.c, and the header has comments
   tersely explaining what inputs each function takes.
  
  devinfo doesn't handle partitions ?
  
  $ devinfo /dev/sda
  /sys//devices/pci:00/:00:13.1/:03:06.0/ata1/host0/target0:0:0/0:0:0:0/block/sda/device
  $ devinfo /dev/sda1
  $
 
 A partition has no device link; there's nothing you get from sysfs
 besides this is partition 'n', here's the alignment, here's where it
 starts and ends, and by the way here's a bunch of stats about how much
 use it's seen this boot.
 The device link contains information like the driver in use, modalias,
 model, vendor, and a whole bunch of other things; and everything I was
 after was in the device link.

Ok, only things that has device then.

 If it's meaningful, I can change this behavior; but that *will* 
 break the trick I mention -
 cat `devinfo /dev/input/node`/name
 depends on going into .../device
 
 Or I could add an option to just get the DEVPATH.

No need, just naively testing the stuff, pressing random buttons and
see what happens.

...
   On debian, devuan, and related distros, you will need to install with:
   make LIBDIR=/usr/lib/$TRIPLET install
   On non-pure64 64-bit installs of other distros, you will need to set
   LIBDIR to point to the appropriate directory (lib32 or lib64).
  
  Works fine on a pure 32-bit debian.
 
 Installing directly in /usr/lib will work, but for packaging multiarch
 is important.

Can't help you there for the moment.

Regards,
/Karl Hammar

---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


Re: [Dng] sugestion apulse as pulseaudio replcement

2015-01-23 Thread Javier Ortega Conde (Malkavian)
Hi Sean:

 I would love to see jack as a default or as an optional package with sane
 defaults. If pulse is really needed,it works as a jack client. I have to
 kill -9 pulse frequently as it leaks badly and won't die; jack only goes
 crazy when I misconfigure it.

I would love to to have Jack as default. I use it in my personal computer
and it works like a charm. With the application Cadence I configured
bridges from alsa and pulseaudio to pass all the sound to Jack. Apulse
solution would be better I suppose.

For avoiding pulseaudio respawn edit /etc/pulse/client.conf uncomment
(delete the semicolon) line ; autospawn = yes and change it to now. Now
if you kill pulseaudio with command:  pulseaudio -k
It won't respawn.

-- 
Agur: Javier Ortega Conde (Malkavian)

Miembro de Club de Go de Bilbao (GoBi)   http://gobi.webnode.es
Miembro del Grupo de LinUxuarios de Bizkaia, Eghost, Itsas, Aske...
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


Re: [Dng] sugestion apulse as pulseaudio replcement

2015-01-23 Thread Michael Dec

On 2015-01-23 10:16, Javier Ortega Conde (Malkavian) wrote:

Hi Sean:


I would love to see jack as a default or as an optional package with
sane defaults. If pulse is really needed,it works as a jack client.
I have to kill -9 pulse frequently as it leaks badly and wont die;


You mean it's leaking memory? Is there a bug filed against PA for this?
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


Re: [Dng] sugestion apulse as pulseaudio replcement

2015-01-23 Thread Steve Litt
On Fri, 23 Jan 2015 11:16:08 +0100
Javier Ortega Conde (Malkavian) malkavian...@gmail.com wrote:

 Hi Sean:
 
  I would love to see jack as a default or as an optional package
  with sane defaults. If pulse is really needed,it works as a jack
  client. I have to kill -9 pulse frequently as it leaks badly and
  won't die; jack only goes crazy when I misconfigure it.
 
 I would love to to have Jack as default. I use it in my personal
 computer and it works like a charm. 

Guys, in the past I've tried to get Jack running about four or five
times, and never succeeded. This included the sound studio version of
Ubuntu. I'm sure that Jack is perfect for the dedicated sound
enthusiast, but for the average guy, Jack just might be the only thing
that could cause more failure than Pulse. Jack is very, very
complicated.

SteveT

Steve Litt*  http://www.troubleshooters.com/
Troubleshooting Training  *  Human Performance

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


Re: [Dng] Upgrade paths

2015-01-23 Thread Go Linux


On Thu, 1/22/15, Franco Lanza next...@nexlab.it wrote:

 Subject: Re: [Dng] Upgrade paths
 To: dng@lists.dyne.org
 Date: Thursday, January 22, 2015, 11:43 PM

 
 Any other paths we should think about?
 
  Only one another path should be officially supported: the install from 
 scratch using devuan installer
 
 ___

Yes!  This is how I will be installing Devuan.  I always install a new release 
from scratch and keep the old install around as a backup.  ;)

golinux
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng