1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140
|
Some notes on the Xing mp3 encoder.
The Xing Mp3 encoder for linux is by far the fastest encoder available, and
produces good quality MPEG1 and MPEG2 streams.
When the beta version was released I quickly hacked liveice to work correctly
with it - at least it worked well in mono mode, stereo was broken and didn't
work. When the production verions appeared something had changed which managed
to stop it working completely with liveice.
Basically xing has problems reading from pipes - this is annoying if you want
to record audio live and encode it since they've managed to make this a
difficult task.
There are 2 solutions which are possible.
Solution 1
==========
The first allows mono encoding without any modification to LiveIce, and a
simple modification to the Linux kernel.
(1) Go to you kernel source directory, and edit fs/pipe.c
(2) find the line
static long long pipe_lseek(struct file * file, long long offset, int orig)
{
return -ESPIPE;
}
This basically returns an error if somethign tries to seek on the pipe.
(3) comment this out and replace it with
static long long pipe_lseek(struct file * file, long long offset, int orig)
{
if(orig==2)
return 2147483647;
if(offset>=0)
return offset;
else
return -offset;
}
this returns some numbers which make pipes look like very long files when
programmes try to seek in them. Xing seeks to teh end of the file to find
out how long the file is and allocates a buffer based on this, if it gets an
error it somehow decides it doesn't need an output buffer.... so this makes
the pipe look like a 2GB file. Xing doesn't do any thign strange after it
passes 2GB of data so there's no real limit - I would try larger numebrs
except I suspect that the xing code would have problems.
(4) recompile and reinstall the kernel....
Now this changes the behaviour of all pipes... but I haven't found anything
which has a problem with this. and the code is probably more stable and
secure than my seconds - more complicated option.
Solution 2
==========
The second option works for stereo modes as well but requires you to load
a kernel module which I've written and, judging by the number of problems
that people have with my liveice code this could be a dangerous prospect.
I think you'd have to be mad to let my code contaminate your kernel ;-)
Basically these instructions are guidelines and I can't gurantee that this
won't trach your system, but then again I can't think of any way that might
happen. So, no guranatees, but don't let that stop you.
It installs a device handler for a new type of device which is similar to a
pipe but with a larger buffer and capable of handling large reads. In
Stereo mode the xing encoder asks for 27Kbytes in each read (strange number,
don't ask me why) and decides that it's reached the end of the file when it
gets given any less. This is needless to say very annoying when a normal
pipe will only handle reads and writes of 4096 bytes. So this special
pipe can handle those big reads and writes, and as a bonus buffers more data
in the hope of reducing the number of calls to the scheduler and improving
overall performance.
(1) compile livepipe.c
$ gcc -DMODULE -D__KERNEL__ -DLINUX -O -c livepipe.c
(2) modify liveice to be less paranoid about its pipes
edit liveice.h and comment out
#define PARANOID_PIPES
and recompile liveice - this just stops it quitting when it finds a device
where it expects a pipe.
(3) now load the module and check the kernel messages to see what device
number it's been allocated - you need to be root to do this.
# insmod livepipe
# dmesg | tail
Jul 11 17:36:15 arpc65 kernel: I suggest you use:
Jul 11 17:36:15 arpc65 kernel: mknod <name> c 254 <minor>
Jul 11 17:36:15 arpc65 kernel: minor number 0-15 are valid for this device
Jul 11 17:37:00 arpc65 kernel: Removing module from kernel
Jul 11 17:37:12 arpc65 kernel: Registration is a success. The major device numbe
r is 254.
Jul 11 17:37:12 arpc65 kernel: If you want to talk to the device driver,
Jul 11 17:37:12 arpc65 kernel: you'll have to create a device file.
Jul 11 17:37:12 arpc65 kernel: I suggest you use:
Jul 11 17:37:12 arpc65 kernel: mknod <name> c 254 <minor>
Jul 11 17:37:12 arpc65 kernel: minor number 0-15 are valid for this device
(4) now in the directory you normally run liveice from there will be a
directory called .liveice_temp_files full of files called mpeg.pipeX and
raw.pipeX
you want to replace some of the raw.pipeX files with livepipe devices -
# cd .liveice_temp_files
# ls -l
total 0
prw------- 1 spm spm 0 Jul 12 13:30 mpeg.pipe0
prw------- 1 spm spm 0 Jun 27 16:42 mpeg.pipe1
prw------- 1 spm spm 0 Jul 12 13:30 raw.pipe0
prw------- 1 spm spm 0 Jun 27 16:42 raw.pipe1
# rm raw.pipe0
# mknod raw.pipe0 c 254 0
You only need to replace the pipes which are going to be used by stereo
channels.
(5) setup liveice.cfg and run it
(6) Rejoice as you broacast 128Kbit stereo!
I'd like to incorporate the pipe device creation into liveice but I'm
a bit dubious for the moment...
Copyright 1999 Scott Manley
|